Bugzilla – Bug 3841
Thumbnail artwork not displayed properly after normal scan
Last modified: 2008-09-15 14:39:24 UTC
I added a few new albums today with folder.jpg files in each folder. I did a normal rescan to find new music. Some of the album artwork thumbnails are not displayed in "New Music" gallery view. When I browse to the album, I get the full size artwork. I checked the tags - there is no embedded artwork.
you need to clear and rescan. this requirement came back with the post-scan artwork scan.
Did that work for you, Philip?
Yes, that worked. A clear and rescan isn't exactly a nice solution though. Is this just a temporary workaround - can something be done to fix it for normal scan / Browse Music Folder?
It is the same solution as all previous versions since browse artwork began. There was a short time in the nightlies where it was removed, but some users were having problems...or so I'm told. Dan?
The issue was actually that every album was being set to having artwork, so even if it didn't, we would process the 'unknown artwork' image for all of the albums during artwork display. With the fixed post-process scan, we're able to see that an album doesn't have artwork and let the browser cache the unknown image properly. The question is - is the artwork scan running properly after a rescan. I need to look.
Using BMF for artwork was filed as bug 2116, which was closed at the point where artwrok was collected on teh fly. as this is no longer the case, either that bug should be reopened or this one takes it's place with an appropriate summary. would be an ideal if on the fly could work. perhaps a check against mtime would tell if something in the folder/file has changed in order to give a hint that maybe artwork was added? That could be part of a 'new and changed' scan, perhaps.
Tested & Fixed in change 8870. Works with both a normal rescan, and Browse Music Folder.
Very nice. Thanks.
The applied fix makes browsing the Music Folder extremely slow, especially on large collections as the call to findArtwork is searching every sub dir of the current top-level dir. There's no need for this. When browsing the music folder, slimserver only needs to look for artwork at the current directory level. Can findArtwork be prevented from descending into subdirs? R.
I also noticed that Browse Music Folder was very slow and traced it back here. The largest problem is that if you've got a paged music folder, on each page it will re-run the entire artwork scan on all subdirs. Could we maybe run the artwork scan only via normal scanning with scanner.pl? Or how about not scanning for image tags if the file mtime has not changed? The tag scan is eating the most time during this process.
I'm not sure how to achieve it, but the fix would be for the FindArtwork routine to not descend into subdirs, i.e. only check the current directory. That would still be reasonably fast and would show the relevant information (i.e. any artwork in the current directory) Perhaps add a "maxdepth" parameter to the FindArtwork routine? BTW, can someone re-open this bug? R.
That's not the correct fix, since a SQL query has no concept of recursion. The fix is to check that the $path is not eq to audiodir & to use the timestamp field as a filter.
Hmm, I'm not sure I understand what's happening here. Why is BrowseMusic folder looking in the DB for artwork? I had hoped I could fix this, but I think I may have to leave it for those who understand the code more! R.
Change 9014 should fix this issue.
Much better, thanks.
From change 9014: > Description: Don't search the entire tree when looking for artwork via BMF. Only search if we've gotten a change. Does this mean that BMF will find artwork for newly added music, and for tracks that have a changed mtime, but it won't pick up newly added or changed artwork?
It should pick up new artwork as well. I'm going to close this, as the main issue has been fixed. Please open additional bugs for any follow-on issues. Thanks