OpenLP can't continue when saving service with linked audio

[Derek Robin Chambers]

**OpenLP Bug Report**
Version: {u'full': u'1.9.8', u'version': u'1.9.8', u'build': None}

--- Details of the Exception. ---

This happens on saving a service that includes a song with linked audio. The error seems to mean just "C:\Users\Derek\AppData\Roaming\openlp\data\servicemanager\audio\74327d51-5f94-11e1-871d-f04da2c5376a\10 Misericordias Domini.m4a is missing".

Three workarounds
a. Identify the song with the linked audio, remove from service and proceed with the Save.
b. Unlink the audio, update the song in the service and Save
c. If the audio track is available, copy it into the empty parent folder, in this case data\servicemanager\audio\74327d51-5f94-11e1-871d-f04da2c5376a, and Save

Can't really see how this situation arises though - the audio is present in AppData\Roaming\openlp\data\songs\audio\260.

Couple of possible culprits:

1. I do a lot of export/import of services between various machines, relying mainly on the automatic song import that is performed when a service contains a new song. Deliberately failing to send audio tracks as separate files and hence not relinking them on the target machine do not trigger this problem (although I can only test this with mp3 files today whereas I have only seen the problem with m4a files).

2. Also, following a disk crash and reload of Windows 7 from scratch I reinstated the entire AppData\Roaming\openlp\data folder from a Norton Ghost before doing anything else with OpenLP.

The system is Dell M5010; Athlon II P360 running Windows 7 Home Premium 64-bit service pack 1.

 --- Exception Traceback ---
Traceback (most recent call last):
  File "D:\OpenLP_Code\release-1.9.8\build\pyi.win32\OpenLP\outPYZ1.pyz\openlp.core.ui.servicemanager", line 579, in saveFile
  File "D:\OpenLP_Code\release-1.9.8\build\pyi.win32\OpenLP\outPYZ1.pyz\shutil", line 84, in copy
  File "D:\OpenLP_Code\release-1.9.8\build\pyi.win32\OpenLP\outPYZ1.pyz\shutil", line 48, in copyfile
Error: `C:\Users\Derek\AppData\Roaming\openlp\data\servicemanager\audio\74327d51-5f94-11e1-871d-f04da2c5376a\10 Misericordias Domini.m4a` and `C:\Users\Derek\AppData\Roaming\openlp\data\servicemanager\audio\74327d51-5f94-11e1-871d-f04da2c5376a\10 Misericordias Domini.m4a` are the same file

--- System information ---
Platform: Windows-7-6.1.7601-SP1

--- Library Versions ---
Python: 2.6.6
Qt4: 4.7.1
Phonon: 4.4.0
PyQt4: 4.8.3
QtWebkit: 533.3
SQLAlchemy: 0.6.6
SQLAlchemy Migrate: 0.7.1
BeautifulSoup: 3.2.0
lxml: 2.2.4
Chardet: 1.0.1
PyEnchant: 1.6.5
PySQLite: 1.0.1
Mako: 0.4.1
pyUNO bridge: -

[Jonathan Corwin (j-corwin)]

I thought I'd seen this myself, but I can't seem to reproduce it now

[Derek Robin Chambers (derek-chambers)]

Found a couple more songs that caused this and made a few further observations:

1. Completely repeatable: if song (with linked audio) causes it at all, it will cause it in every service to which it is added, including brand new services containing nothing else.
2. Checked through the songs and media_files sqlite files; verified that the songs were where the sqlite files said they should be, in openlp\data\songs\audio\<songid> and that they were not corrupted, i.e. were playable by VLC player.
3. Once such a song has been added to a service, one further save can be done - the "Oops OpenLP can't continue" does not occur until the second or subsequent save after the 'dodgy' song has been added.
4. On that first save, an empty uniquely-named folder is created inside openlp\data\servicemanager\audio and it remains empty for the subsequent saves.
5. If two 'dodgy' songs are added to a service and a save done, apparently without error, only one empty uniquely-named folder is created inside openlp\data\servicemanager\audio

I suspect it's caused by the original audio being moved from the location it was in when the audio-link was defined but I can't find anywhere in the sqlite tables that specifies the original audio location - only the location of the copy in openlp\data\songs\audio\, which I have verified to be OK.

[Jonathan Corwin (j-corwin)]

I'm going to have to ask you, if you have the time, to please try and reproduce this from scratch if at all possible and document the exact steps you took. You also said you could only get the error with m4a files but not mp3's which is a bit odd.

I do see the increase of folders in the data\songs\audio folder, but can't get an error to occur, either in 1.9.8 or the latest build.

[Derek Robin Chambers (derek-chambers)]

Sorry, forgot to say, songs I found exhibiting the problem this last weekend involved linked mp3 files, so the problem is not confined to m4a.

[Raoul Snyman (raoul-snyman)]

Derek, can you download tomorrow's nightly build and see if you can still reproduce this? I fixed your other bug and it should be in the next nightly, and I do wonder if the two are somehow related.

[Raoul Snyman (raoul-snyman)]

Hi Derek, have you tested this out?

[Derek Robin Chambers (derek-chambers)]

Er, I think I might be using the wrong nightly build. I tested "latest.exe" from your downloads page http://openlp.org/en/download last night, which was OpenLP-1.9.8-bzr1904-setup.exe (MD5=134a72a43cbbf15aed20f1091bc2ad65). Both problems still occur (debug log attached). I assumed I had just tested it too soon so waited a day and tried again tonight but find that "latest.exe" still downloads the same file. So neither problem seems to be fixed in the 1904 windows build that I am picking up.

I am now more strongly suspicious that this bug #941966 is caused by the audio track not being where it was when it was linked to the song originally. Two reasons:
1. A particular song I've just been looking at is definitely in a different location on this laptop from the machine on which the song/audio were linked originally.
2. Copying the track from Roaming\openlp\data\songs\audio to the Desktop and linking that copy to the song instead fixes the problem for that particular song.

One more piece of info, about bug #888815: once the problem has been triggered by saving service, the time-remaining counter that you have (very usefully thank you) added beside the pause button in the Live panel does not change when hitting unpause to start (unsuccessfully) playing the track. Neither does it change if then hit pause (don't expect it to). Hitting unpause again though changes it to -1:59, where it remains however many times you toggle the pause button. I've tried this for 3 different songs - the time it sticks at is always -1:59. I'll now add this to the #888815 bug where it belongs.

[Raoul Snyman (raoul-snyman)]

When you tested the build, did you try to create a service from scratch? Or did you try to load a server you'd already made with a previous version?

[Derek Robin Chambers (derek-chambers)]

New services from scratch only.

On 16/03/2012 22:40, Raoul Snyman wrote:
> When you tested the build, did you try to create a service from scratch?
> Or did you try to load a server you'd already made with a previous
> version?
>

--
Cheers
/Derek/

[Jon Tibble (meths)]

Hi Derek, A new test build is up here http://builds.projecthq.biz/media-test-OpenLP-1.9.8-bzr1436-setup.exe

Could you try it and let us know if it fixes your issue and also that it doesn't break anything either! Thanks.

[Derek Robin Chambers (derek-chambers)]

Thank you,
Sorry for the delay - the machine that shows this problem happened to be the machine I was using for worship
this morning and I didn't want to take risks until the service was over.

**OpenLP Bug Report**
Version: {u'full': u'1.9.8-bzr1436', u'version': u'1.9.8', u'build': u'bzr1436'}

--- Details of the Exception. ---

One of the songs that causes this problem with other builds was added as the only item in a brand new service. This exception occurred on the FIRST attempt to save the service (in other builds, the exception does not occur until the second and subsequent attempts to save the service).

The "WindowsError: [Error 5] Access is denied: u'C:\\Users\\Display\\AppData'", which doesn't occur with other builds, highlights one quirk of my particular machine: while the linked audio track does exist, at C:\Users\Display\Music\iTunes\iTunes Media\Music\Helen Cornelius\Karaoke Version\26347 Mary Did You Know.mp3, there is no Display account on this machine. The folder C:\Users\Display contains nothing else apart from the Music subfolder (to avoid needing to edit iTunes playlists when exchanging them with other church machines that do have a Display account) - in particular there is no C:\Users\Display\AppData. If, for some reason, OpenLP is attempting to generate new stuff in C:\Users\Display, it will run foul of windows UAC. But should it be writing new stuff in C:\Users\Display if my account is Derek, in C:\Users\Derek?

 --- Exception Traceback ---
Traceback (most recent call last):
  File "D:\OpenLP_Code\media-test\build\pyi.win32\OpenLP\outPYZ1.pyz\openlp.core.ui.servicemanager", line 457, in saveFile
  File "D:\OpenLP_Code\media-test\build\pyi.win32\OpenLP\outPYZ1.pyz\openlp.core.ui.servicemanager", line 639, in saveFileAs
  File "D:\OpenLP_Code\media-test\build\pyi.win32\OpenLP\outPYZ1.pyz\openlp.core.ui.servicemanager", line 554, in saveFile
  File "D:\OpenLP_Code\media-test\build\pyi.win32\OpenLP\outPYZ1.pyz\os", line 150, in makedirs
  File "D:\OpenLP_Code\media-test\build\pyi.win32\OpenLP\outPYZ1.pyz\os", line 150, in makedirs
  File "D:\OpenLP_Code\media-test\build\pyi.win32\OpenLP\outPYZ1.pyz\os", line 150, in makedirs
  File "D:\OpenLP_Code\media-test\build\pyi.win32\OpenLP\outPYZ1.pyz\os", line 150, in makedirs
  File "D:\OpenLP_Code\media-test\build\pyi.win32\OpenLP\outPYZ1.pyz\os", line 150, in makedirs
  File "D:\OpenLP_Code\media-test\build\pyi.win32\OpenLP\outPYZ1.pyz\os", line 150, in makedirs
  File "D:\OpenLP_Code\media-test\build\pyi.win32\OpenLP\outPYZ1.pyz\os", line 157, in makedirs
WindowsError: [Error 5] Access is denied: u'C:\\Users\\Display\\AppData'

--- System information ---
Platform: Windows-7-6.1.7601-SP1

--- Library Versions ---
Python: 2.6.6
Qt4: 4.7.1
Phonon: 4.4.0
PyQt4: 4.8.3
QtWebkit: 533.3
SQLAlchemy: 0.6.6
SQLAlchemy Migrate: 0.7.1
BeautifulSoup: 3.2.0
lxml: 2.2.4
Chardet: 1.0.1
PyEnchant: 1.6.5
PySQLite: 1.0.1
Mako: 0.4.1
pyUNO bridge: -

[Derek Robin Chambers (derek-chambers)]

Very pleased to say that this build OpenLP 1.9.8 build bzr1436 does seem to have fixed my other bug bug #888815 which bzr1904 and bzr1906 didn't fix.
Thank you.