Portable apps storing drive letter in db

I think this should be considered a bug (and should possible be fixed in 2.0 as well).

A would agree with Andreas, this is a bug. It prevents the software from being truly portable. I'm using v2.0.4 Portable to create my service list and export it, then import it onto the church computer the music will not play. This is because of the absolute path in the song db. Please consider this a high priority.
Importance: HIGH

Scott, I don't think this has to do with the absolute path in songs.sqlite but the absolute path in the osz file itself. The portable edition copies all the files embedded in the osz file to the portable folder data/servicemanager/ and than changes the link to that path. That works correct for MP3s in media module but not in songs module.

204_Test_MP3-Path-in-Song.osz\204_Test_MP3-Path-in-Song.osj has
"background_audio": ["D:\\OpenLPPortable\\Data\\songs\\audio\\3\\John Waller - While I'm Waiting (from the FIREPROOF Soundtrack).mp3"]

At opening of the osz the MP3 is copied to
D:\OpenLPPortable\Data\servicemanager\John Waller - While I'm Waiting (from the FIREPROOF Soundtrack).mp3

Can someone correct that error, please? Thanks and be blessed!

---
Traceback (most recent call last):
  File "D:\OpenLP_Code\2.0\build\pyi.win32\OpenLP\out00-PYZ.pyz\openlp.plugins.songs.lib.mediaitem", line 582, in serviceLoad
  File "D:\OpenLP_Code\2.0\build\pyi.win32\OpenLP\out00-PYZ.pyz\openlp.plugins.songs.lib.mediaitem", line 98, in _updateBackgroundAudio
  File "D:\OpenLP_Code\2.0\build\pyi.win32\OpenLP\out00-PYZ.pyz\shutil", line 82, in copyfile
IOError: [Errno 2] No such file or directory: u"D:\\OpenLPPortable\\Data\\songs\\audio\\3\\John Waller - While I'm Waiting (from the FIREPROOF Soundtrack).mp3"

Response to #3:

If the file is found:

Traceback (most recent call last):
  File "D:\OpenLP_Code\2.0\build\pyi.win32\OpenLP\out00-PYZ.pyz\openlp.plugins.songs.lib.mediaitem", line 582, in serviceLoad
  File "D:\OpenLP_Code\2.0\build\pyi.win32\OpenLP\out00-PYZ.pyz\openlp.plugins.songs.lib.mediaitem", line 98, in _updateBackgroundAudio
  File "D:\OpenLP_Code\2.0\build\pyi.win32\OpenLP\out00-PYZ.pyz\shutil", line 69, in copyfile
Error: `D:\OpenLPPortable\Data\songs\audio\12\John Waller - While I'm Waiting (from the FIREPROOF Soundtrack).mp3` and `D:\OpenLPPortable\Data\songs\audio\12\John Waller - While I'm Waiting (from the FIREPROOF Soundtrack).mp3` are the same file

I checked again

Error: `D:\OpenLPPortable\Data\songs\audio\13\John Waller - While I'm Waiting (from the FIREPROOF Soundtrack).mp3` and `D:\OpenLPPortable\Data\songs\audio\13\John Waller - While I'm Waiting (from the FIREPROOF Soundtrack).mp3` are the same file

Error message is wrong because there is no file in
D:\OpenLPPortable\Data\songs\audio\13

Its in
Data\servicemanager\John Waller - While I'm Waiting (from the FIREPROOF Soundtrack).mp3

204_Test_MP3-Path-in-Song4.osj has this in it
"background_audio": ["D:\\OpenLPPortable\\Data\\songs\\audio\\13\\John Waller - While I'm Waiting (from the FIREPROOF Soundtrack).mp3"]

Thanks for your investigation GermanGospel, this helps a lot!

OpenLPPortable204\App\OpenLP\plugins\songs\lib\mediaitem.py

---
    def _updateBackgroundAudio(self, song, item):
        song.media_files = []
        for i, bga in enumerate(item.background_audio):
            dest_file = os.path.join(
                AppLocation.get_section_data_path(self.plugin.name),
                u'audio', str(song.id), os.path.split(bga)[1])
            check_directory_exists(os.path.split(dest_file)[0])
            shutil.copyfile(os.path.join(
                AppLocation.get_section_data_path(
                    u'servicemanager'), bga), #ERROR: Should be this? os.path.split(bga)[1]),
                dest_file)
---
It should be copyfile(file from servicemanager path to dest_file), right?

Hi guys, can you try this build and see if it fixes the problem?

http://builds.openlp.org/OpenLPPortable_2.0.4.2192.paf.exe

Thanks, this fixed it for me! :-)

It's a good idea that you only copy the file if its not there:
            if not os.path.exists(dest_file):

Now I have to get my build environment running to fix such small bugs myself! ;-)

Raoul, I think you just fixed the bug that Scott Lavine (salavine1, wrote on 2014-03-28) mentioned. The original bug description points to another bug that I didn't run into. Maybe because the relative path was introduced in 2.0.3?

GermanGospel, the path stored in the service file is still an absolute path, I just stripped it out. It would probably be better to just strip it when the item is added to the service.

What do you mean by "I just stripped it out"? In the corrected def _updateBackgroundAudio or elsewhere?

As follows, in _updateBackgroundAudio:

    os.path.split(bga)[1]

Answer to #12 (path stored in the service file is still an absolute path [...] It would probably be better to just strip it when the item is added to the service)

Why store an absolute path at all? Instead of checking and correcting it every time a item is added to the service I would store only the relative path and build the absolute path for runtime use.

In _updateBackgroundAudio the absolute path (os.path.split(bga)[0]) isn't used at all.

Yep, that's what I said. I was just first testing to see if the logic was correct.

Linked to this issue is that _updateBackgroundAudio is called in the wrong place when searching for the song in the database on loading a service. If a song exists with the same name but different authors, then _updateBackgroundAudio is potentially called with the wrong song argument. In turn this causes the wrong path to the file to be generated, exacerbating the issue.

As part of my pathlib changes made in the development of 2.6 the file paths in the databases should now be stored relative to the data folder.

Need to investigate other aspects of this, but this should no longer be a problem by time I have finished my path lib refactors