Bugzilla – Bug 6491
Album artwork missing and causes perl.exe crash
Last modified: 2007-12-30 05:22:10 UTC
I have an album "Ceux Qui Inventent N'ont Jamais Vécu" that is causing some grief to SqueezeCenter. The album seems to have been scanned correctly - it's displaying the accented characters from the tags correctly, and I can browse the album and play it. However, the artwork doesn't display and causes perl.exe to crash. I the artwork displays fine in other applications. 1. The artwork is missing for the album in the browse albums list (default skin, small artwork display mode). It displays the album name as link text instead, but this overwrites the album name that is usually displayed after the artwork. 2. Cover art doesn't display in album info display. Instead I see a "coverArt" hypertext link. 3. Crash when trying to click on "coverArt" link in the album info dispay. 4. I can play album, but displaying album in webUI crashes perl.exe because it tries to display the album artwork in the current playlist panel. Subsequent restarts of the server crash perl.exe because the webUI is still trying to display the artwork. I'm wondering if the artwork isn't being cached correctly due to accented characters in the source path (the folder name is the album title)? I've seen the following errors in the log: [11:52:31.0373] Slim::Web::Graphics::processCoverArtRequest (428) Can't use GD for application/octet-stream (music/7774/cover_50x50_p.png) [11:52:32.5003] Slim::Web::Graphics::processCoverArtRequest (428) Can't use GD for application/octet-stream (music/5299/cover_50x50_p.png) [11:54:08.9846] Slim::Web::Graphics::processCoverArtRequest (428) Can't use GD for application/octet-stream (music/7774/cover.jpg) [11:57:43.8986] Slim::Web::Graphics::processCoverArtRequest (428) Can't use GD for application/octet-stream (music/7774/cover_50x50_p.png) This may be related to bug 6458, which stops the scanner from crashing. That bug seems to have been fixed, but the crash now occurs elsewhere ;)
Created attachment 2585 [details] file with corrupt embedded artwork that crashes SC. It appears that the problem is due to dodgy embedded artwork in mp3 files; nothing to do with accented characters. Although my folder.jpg is fine, somehow I seem to have a 0x0 jpg (6KB) artwork cover embedded in the first song. The scanner process seems to be fine with this, but it causes the webUI problems mentioned in my initial bug report text. I assume the scanner has tried to read the embedded artwork to store some cached versions of it. Maybe errors are caught but dodgy cached artwork copies are still stored? No errors or warnings are reported during the scan; only when trying to display the artwork in the WebUI do I see errors.
I suspect that this is a dup of bug 4699. Please test both examples when updating GD. *** This bug has been marked as a duplicate of 4699 ***