Bugzilla – Bug 2682
AAC/ALAC Artwork stopped being displayed in 6.2.1
Last modified: 2008-09-15 14:38:10 UTC
Artwork for AAC and ALAC files is no longer being displayed in 6.2.1. When browsing by artwork or album, the web browser shows a blue icon with a question mark. Artwork for MP3 files is being displayed. Display of artwork for AAC/ALAC files certainly used to work but sometime in the last few days it stopped working om my Mac - I'm not sure what has caused this as the only thing changed over this period was clearing and rescanning database when new music was added to the library. I have reinstalled 6.2.1, deleted database file and tried 6.2.2 and AAC/ALAC artwork is still not displayed. Artwork on AAC/ALAC files can be seen using iTunes and Media Rage tagging application. See attached debug file of database clear and rescan with d_artwork, d_scan and d_server on. This was done for 2 files to save time scanning. One file is mp3 and artwork is displayed, the other file is ALAC and artwork isn't dispayed.
Created attachment 1063 [details] debug info during rescan
To add more information to this, I went back to 6.1.1 and could see artwork for both mp3 and AAC files. I then reinstalled 6.2.1, did a clear and rescan but the artwork for .m4a files was no longer displayed. See below for d_artwork debug traces for 6.1.1 and 6.2.1. 6.1.1 .m4a artwork visible 2005-12-05 20:43:18.6097 Updating image for file:///Volumes/MusicServerLaCie/test/02%20Eye%20For%20An%20Eye%20copy.m4a 2005-12-05 20:43:18.6148 Looking for image in Movie metadata in file /Volumes/MusicServerLaCie/test/02 Eye For An Eye copy.m4a 2005-12-05 20:43:18.6193 found image in /Volumes/MusicServerLaCie/test/02 Eye For An Eye copy.m4a of length 120869 bytes 2005-12-05 20:43:18.6231 ID3 Artwork cache entry for Never Never Land: /Volumes/MusicServerLaCie/test/02 Eye For An Eye copy.m4a 2005-12-05 20:43:18.7184 Updating image for file:///Volumes/MusicServerLaCie/test/Back%20In%20Black%20copy.mp3 2005-12-05 20:43:18.7254 Looking for image in ID3 2.2 tag in file /Volumes/MusicServerLaCie/test/Back In Black copy.mp3 2005-12-05 20:43:18.7257 APIC format: image/jpg length: 8921 2005-12-05 20:43:18.7277 ID3 Artwork cache entry for Back In Black: /Volumes/MusicServerLaCie/test/Back In Black copy.mp3 6.2.1 .m4a artwork not visible 2005-12-05 20:48:16.5288 Retrieving artwork (thumb) for: file:///Volumes/MusicServerLaCie/test/02%20Eye%20For%20An%20Eye%20copy.m4a 2005-12-05 20:48:16.5294 Updating image for file:///Volumes/MusicServerLaCie/test/02%20Eye%20For%20An%20Eye%20copy.m4a 2005-12-05 20:48:16.5305 Looking for image in Movie metadata in file /Volumes/MusicServerLaCie/test/02 Eye For An Eye copy.m4a 2005-12-05 20:48:16.5322 found image in /Volumes/MusicServerLaCie/test/02 Eye For An Eye copy.m4a of length 181172 bytes 2005-12-05 20:48:16.5422 Updating Never Never Land artwork cache: /Volumes/MusicServerLaCie/test/02 Eye For An Eye copy.m4a 2005-12-05 20:48:16.5494 Retrieving artwork (thumb) for: file:///Volumes/MusicServerLaCie/test/Back%20In%20Black%20copy.mp3 2005-12-05 20:48:16.5499 Updating image for file:///Volumes/MusicServerLaCie/test/Back%20In%20Black%20copy.mp3 2005-12-05 20:48:16.5525 Looking for image in ID3 2.2 tag in file /Volumes/MusicServerLaCie/test/Back In Black copy.mp3 2005-12-05 20:48:16.5528 APIC format: image/jpg length: 8921 2005-12-05 20:48:16.5581 Updating Back In Black artwork cache: /Volumes/MusicServerLaCie/test/Back In Black copy.mp3 I'm not sure of the exact details between 6.1.1 and 6.2.1 however there are some clear differences between the 2 traces. - for some reason, the "found image" line in 6.1.1 and 6.2.1 have different byte lengths for the same .m4a file (but the length is the same for the .mp3 file) - 6.1.1 has "ID3 Artwork cache entry for <track>" while 6.2.1 has "Updating <track> artwork cache:" It appears to me that the cache for .m4a artwork isn't being updated therefore the .m4a artwork is displayed as blank on the browser. I have cleared the cache on browsers and the problem happens using both Safari and Firefox on the local computer and Safari, Firefox and IE on another computer.
The debug shown here is for the collection of tumbnails used in Browse Artwork. Does the artwork come up blank always or just specific places? You've mentioned browse artwork, and browse album. The two other places of interest would be the song info page and the now playing section at the top right. would you be willing to attach the song from your log to this report?
Created attachment 1065 [details] more debug info during recan d_artwork and d_info during rescan of files for 6.1.1 where .m4a file artwork can be seen and 6.2.1 where the artwork can't be seen
(In reply to comment #3) > The debug shown here is for the collection of tumbnails used in Browse Artwork. > Does the artwork come up blank always or just specific places? You've > mentioned browse artwork, and browse album. The two other places of interest > would be the song info page and the now playing section at the top right. > > would you be willing to attach the song from your log to this report? > kdf - the artwork comes up up blank always - when browsing by album, artwork or song info. The m4a file is a bit too big to attach (41M) however I can put it on an ftp server if you can provide an address. I have used a server ftp.electricrain.com/incoming when sending files to Dan and Dean for investigation but I don't know if you have access to this. I'm doing some more investigation and will post up more info on the bug report.
no problem. I'm sure Dan can handle this eventualy. I wonder if this might be related to the switch from the homegrown Movie.pm to teh MP4::Info module from cpan. If you are debugging, you could try setting line 32 to "my $debug = 1;" in lib/MP4/Info.pm to see more details on teh tag extraction on those aac files.
(In reply to comment #6) > no problem. I'm sure Dan can handle this eventualy. I wonder if this might be > related to the switch from the homegrown Movie.pm to teh MP4::Info module from > cpan. If you are debugging, you could try setting line 32 to "my $debug = 1;" > in lib/MP4/Info.pm to see more details on teh tag extraction on those aac > files. > I've looked at the d_artwork and d_info debug traces during a rescan and noticed the following. The size of the image in the mp3 file is the same in 6.1.1 and 6.2.1 traces (8291 bytes) but the size of the image in the m4a file is different (6.1.1 is 120869 bytes and 6.2.1 is 181172 bytes) I exported the images from the m4a and mp3 file using a tag editor and the size of the image files agreed exactly with the 6.1.1 trace - 8291 bytes for the image in the mp3 file and 120869 bytes for the image in the m4a file. It looks like the size of the image in the m4a file in the 6.2.1 traces is wrong. The traces also show the following:- 6.1.1 Looking for image in Movie metadata in file /Volumes/MusicServerLaCie/test/01 Eye For An Eye copy.m4a found image in /Volumes/MusicServerLaCie/test/01 Eye For An Eye copy.m4a of length 120869 bytes found PNG image ID3 Artwork cache entry for Never Never Land: /Volumes/MusicServerLaCie/test/01 Eye For An Eye copy.m4a 6.2.1 Looking for image in Movie metadata in file /Volumes/MusicServerLaCie/test/01 Eye For An Eye copy.m4a found image in /Volumes/MusicServerLaCie/test/01 Eye For An Eye copy.m4a of length 181172 bytes Updating Never Never Land artwork cache: /Volumes/MusicServerLaCie/test/01 Eye For An Eye copy.m4a It looks like in 6.2.1 the image file isn't being correctly identifed as a PNG file (or a jpg) Is this because in Slim::Music::Info, the file doesn't meet the tests for PNG or JPG? That could happen if the reference to the image is incorrect which could mean something must have gone wrong previously in MP4/Info.pm. I'll do some more digging.
(In reply to comment #6) > no problem. I'm sure Dan can handle this eventualy. I wonder if this might be > related to the switch from the homegrown Movie.pm to teh MP4::Info module from > cpan. If you are debugging, you could try setting line 32 to "my $debug = 1;" > in lib/MP4/Info.pm to see more details on teh tag extraction on those aac > files. > I changed the line in Info.pm to my $debug = 1 but the debug traces didn't seem to show anything different from the last attachment. Do I need to do something different to get the information?
the debug from the cpan module won't be in the log. it would be dumped to STDOUT, so running from terminal would be best to dig into that.
(In reply to comment #9) > the debug from the cpan module won't be in the log. it would be dumped to > STDOUT, so running from terminal would be best to dig into that. > hmm... I've on a Mac using OSX so can pull up a terminal window but don't know how run slimserver from there or get access to STDOUT...
File "01 Eye For An Eye copy.m4a" has been uploaded to ftp.electricrain.com + an observation from the traces attached. The tag information shown after a rescan on 6.1.1 and 6.1.2 is the same except for the following: 6.2.1 has tags for AUDIO (1), REMOTE (0), DRM (0) and TITLESEARCH (EYE FOR AN EYE) 6.1.1 has tags for RATE (65536) The following tags are in both but have different values SIZE 6.1.1 is 43399384, 6.2.2 is 43113330 SECS 6.1.1 is 345.746666666667, 6.2.2 is 346 BITRATE 6.1.1 is 1004189.20982608, 6.2.2 is 974000
cd /Users/userxx/Library/PreferencePanes/SlimServer.prefPane/Contents/server or cd /Library/PreferencePanes/SlimServer.prefPane/Contents/server perl slimserver.pl the debug shoudl show the contents of each item extracted for tags. It may or may not be of any use to your dig, depending on how much it actually shows. You might learn something, or you might decide to just wait for dan to check the file on his ftp site :) good luck!
Created attachment 1066 [details] Debug info from mp4 info.pm debug info turned on in file mp4 info.pm Rescan done and contains tag info for m4a file. Artwork doesn't display properly on m4a files.
To add further information, I installed Slimserver on a different Mac also running OSX 10.4.3 and reproduced the problem - m4a file artwork was not displayed.
Michael - can you verify this is still an issue with the latest 6.2.2 nightly? If so, can you attach a file that exhibits this problem? Thanks.
I tried this with SlimServer_6_2_x_v2006-04-22.dmg and did a rescan of the library and the problem still exists. When browsing by artwork or individual album, the cover art is not displayed, instead the browser interface shows an icon with a blue square and a question mark. I have copied the ALAC file "01 Introduction.m4a" to ftp.electricrain.com/incoming I am running Mac OSX 10.4.6 on a Mac Mini
Fixed in change 7045
I tried SlimServer_6_2_x_v2006-04-23 nightly and the album artwork for ALAC and AAC files is displayed correctly - but mp3 file artwork isn't. See attached screenshot where all undisplayed albums are mp3. I have copied one of the problem mp3 files to ftp.electricrain.com/incoming File name is "1_Musica__Alex_S_Classic_Cl.mp3" I add artwork to files using iTunes, in most cases, just drag and dropping the jpg artwork of the CD on amazon or the record company website.
Created attachment 1195 [details] screenshot of artwork display artwork displayed is from AAC/ALAC files. artwork not displayed is from MP3 files.
Michael - MP3 artwork should be fixed now as well with the latest nightly. Please verify. Thanks
everything seems to be fixed in the 04-25 nightly, thanks,