#12 Persistent file handle with embedded art

[Markus]

Hi

I got a problem with this scenario:
- I start a search for an album with MP3s with embedded cover art
- there are at least 11 MP3s in the folder (limit for local is set to 10=
- after AAD opened I am not able the write to track no 11
- when I close the AAD gui the program doesn't stop (TaskManager) and the file is still read-only
- after I kill AAD manually I can change the track

That problem doesn't occur when there is no embedded art or there are just ten or less tracks for the album.

Greets
Markus

[AlexVallat]

Thank you for reporting this. I haven't been able to reproduce this problem here, though. Could you try setting the limit for local to 1, and having a folder with only 2 MP3s in the folder? I doubt there's anything special about the number 10, but we might as well check. I assume this happens for any folder for you, not just one specific album?

Also, if you aren't already doing so, please try with only the local file source and no other selected, so we can elminate any possibility of interference by another source.

Thanks,

Alex

[Markus]

I checked it again and it seems that there has to be a jpg in the folder with its file property set to read-only. Its Name is not important.

The problem occurred always with all filters active and seldom with just the local filter.

I got a pretty slow internet connection (248KB/s) maybe that is a point.
The program doesn't always hangs when you close it. It just needs up to 10 seconds to end, I guess while it waits for all connections to end. But 3 times (out of ~50) it kept running.

So these seem to be the required conditions:
- read-only jpg
- more tracks than the filter limit

Thanks for your efforts!

[AlexVallat]

Hmm. It is certainly possible that a long running script might prevent the AAD process from exiting, as it has to wait for the current in-progress internet connection to complete or fail. If the server is slow to respond, this could take a few seconds.

It is very odd that the read-only status of the jpg should matter. Until you actually try and save the image, it won't even attempt to open it with Write access, so it wouldn't know if it was read-only or not.

If it only happens when you have multiple sources being searched then it's probably some strange timing issue, but unless I can reliably reproduce it here I doubt I'll be able to fix it.