Bugzilla – Bug 952
Artwork-reading with %ALBUM does not work in 6.0a2
Last modified: 2008-12-15 13:06:19 UTC
In slimserver.pref I have this: lookForArtwork = 1 coverArt = %ALBUM_std coverThumb = %ALBUM artfolder = D:\Slim\Covers When I run slim.exe --d_artwork i get this result: 2005-03-05 08:23:10.0948 Looking for image files in D:\Music\10cc - Greatest Hits - 1975 2005-03-05 08:23:10.1301 Variable Cover: .jpg from ALBUM_std 2005-03-05 08:23:10.1306 Image File empty or couldn't read: D:\Music\10cc - Greatest Hits - 1975\.jpg 2005-03-05 08:23:10.1334 Image File empty or couldn't read: D:\Slim\Covers\.jpg 2005-03-05 08:23:10.1377 Looking for image files in D:\Music\10cc - Greatest Hits - 1975 2005-03-05 08:23:10.1470 Variable Thumbnail: .jpg from ALBUM 2005-03-05 08:23:10.1476 Image File empty or couldn't read: D:\Music\10cc - Greatest Hits - 1975\.jpg 2005-03-05 08:23:10.1503 Image File empty or couldn't read: D:\Slim\Covers\.jpg This works in 5.4
re-categorising
Is this still an issue with 6.0.1 ? I've not dived in quite yet.
Yes. But I see the problem only on the Home / Browse Artwork page (which displays thumbnails). When on the Home / Browse Artwork / <Album> page then the larger cover image appears correctly.
the large cover is read on teh fly, browse artwork is not. the infoformat stuff isn't available with the current filescan process looks for artwork, so the variable cover art always comes up blank.
We're considering changing the format formatting to make it easier to parse on the machine side. I believe fixing that would fix this bug.
This seems very close. All that is needed now, from current 6.2 builds is to defer artwork checking DURING folder scan so that a communal scan takes place after all importing has completed. folder scan should simply compile the list of albums to check in the same way that the other importers do. I'll work on this.
*** Bug 1841 has been marked as a duplicate of this bug. ***
Created attachment 710 [details] restore strings and defer artwork in folder scan This needs a bit more testing with folder scan, but it should defer the artwork and allow the infoFormat/variable artwork names to be re-enabled. Moser's new code seems to like it so far.
Looks like this patch, combined with Moser's new infoFormat are going to make this work. Dan, let me know if/when you want this dropped in.
I think this looks ok - what is the pref you are removing? Also, I believe that with this, the entire Slim::DataStores::DBI::DBIStore::_findCoverArt() method can go away, as that was the only caller.
no pref removed. artworkFolder was commented out since it was useless while this didn't work. I'm re-enabling it, and putting the prefs list back into two lines to keep it neat and tidy :) will double check the _findCoverArt calls and check in soon
committed to trunk at change 3933. should be working nicely now. re-open if there are issues.
This bug appears to have been fixed in the latest release! If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look. Make sure to include the version number of the software you are seeing the error with.