Bugzilla – Bug 13596
back cover is shown instead of front cover
Last modified: 2009-10-05 14:28:28 UTC
If there is a back cover IN the file this is shown. I only have two covers in some flac files, so I don't know if it is flac only. This is in the web ui and on the controller.
The artwork is embedded in the FLAC file, not in the folder that contains the FLAC files correct?
yes, in the flac are front and back. in the folder is just "folder.jpg" which is also the front cover. but web ui and controller show the back cover. did that with dbpoweramp.
Can you post the output of metaflac --list for this file?
here the link for two files incl. folder.jpg (17MB). AUDIO.zip http://www.sccs.ch/sample/AUDIO.zip Note: I used dbpoweramp to create them and in 7.3.x covers were correct.
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
The metadata has back cover first, front cover second. The Audio::Scan module passes all pictures as an array and Squeezeboxserver only grabs the first one. From the docs on Audio::Scan, I'm not sure you can tell what each image is unless the "picture type" is fully descriptive.
== Auto-comment from SVN commit #28300 to the slim repo by andy == == https://svn.slimdevices.com/slim?view=revision&revision=28300 == Fixed bug 13596, use lowest numbered FLAC picture type when a file contains multiple images
Andy, I'm not sure what the odds are of the feature being used, but doesn't the fix still pose a problem if a user/app makes use of the icon image features (or really any of the 0-2 pictures)? Would the performance his be too much if you were to do a grep for type 3 and fall back to the first image found if that fails?
I'm not too worried about performance, as likely almost nobody does this. Good point about image types < 3. Do you want to improve it so it prefers images in a certain order or something?
I had something partly worked up when I saw your commit. I'll submit a patch when I get some time to redo it later tonight.
Created attachment 5709 [details] specifically look for front cover This version grabs all type 3 (front cover) images and uses the first one (more than one type 3 is allowed in the spec). If there is no type 3 found, then it falls back to what you have already which is to use the lowest picture_type found.
Thanks, looks good. Feel free to apply.
== Auto-comment from SVN commit #28310 to the slim repo by kdf == == https://svn.slimdevices.com/slim?view=revision&revision=28310 == Bug: 13596 Description: specifically grep for front cover art (type 3) in FLAC files before simply falling back to lowest picture_type found.
done. auto comment is convenient. I haven't noticed changelog updates lately. Are those on hold or is there an auto update for that too?
I don't generally put things in the changelog if the bug occurred only within 7.4. If this was broken in earlier versions then we should add it to the changelog.
right. It doesn't look like ALLPICTURES was even supported in earlier versions, so I'll leave it.
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.