Bugzilla – Bug 6458
Scanner crashes during artwork scanning phase on corrupt JPEGs
Last modified: 2009-09-08 09:18:17 UTC
I deleted my SC cache folder and kicked off a full rescan. The music library was fully scanned, but during the artwork scanning, perl.exe crashed. Most of my artwork is in folder.jpg files, although I recently started to add artwork as tags within .mp3 or .flac files. In SqueezeCenter Settings -> Previous Scan Results, I can see the following: Artwork Scan (1253 of 1638) Running 00:30:14 All Is Dream SqueezeCenter has finished scanning your music collection.00:44:11 I assume that "All Is Dream" was the last successful artwork to be scanned, because I can browse to that album in the WebUI and see that cover (it's also been in my library for years). I looked in the scanner.log file; the end of the log looked like this: [21:46:58.6929] Slim::Music::Import::runScanPostProcessing (352) Starting findArtwork(). [21:46:58.6940] Slim::Utils::Cache::new (136) Version changed for cache: Artwork - clearing out old entries [21:49:00.6297] Slim::Web::Graphics::processCoverArtRequest (422) Can't use GD for music/5299/cover_50x50_p.png [21:49:00.6470] Slim::Web::Graphics::processCoverArtRequest (422) Can't use GD for music/5299/cover_56x56_p.png [21:49:00.6673] Slim::Web::Graphics::processCoverArtRequest (422) Can't use GD for music/5299/cover_100x100_p.png [21:49:59.0895] Slim::Web::Graphics::processCoverArtRequest (422) Can't use GD for music/7774/cover_50x50_p.png [21:49:59.1081] Slim::Web::Graphics::processCoverArtRequest (422) Can't use GD for music/7774/cover_56x56_p.png [21:49:59.1262] Slim::Web::Graphics::processCoverArtRequest (422) Can't use GD for music/7774/cover_100x100_p.png [21:52:08.4415] Slim::Web::Graphics::processCoverArtRequest (422) Can't use GD for music/12558/cover_50x50_p.png [21:52:08.4662] Slim::Web::Graphics::processCoverArtRequest (422) Can't use GD for music/12558/cover_56x56_p.png [21:52:08.4916] Slim::Web::Graphics::processCoverArtRequest (422) Can't use GD for music/12558/cover_100x100_p.png How can I determine what source file or album is causing artwork scanning to crash, so I can investigate further? I've set "(scan) - All Scan Logging" to Debug level, and repeated the crash, but I didn't get any more useful information in the log.
Created attachment 2561 [details] The dodgy file causing the scanner crash The attached folder.jpg appears to be corrupt, causing the crash. I found the faulty file in the end by using SysInternals Process Monitor to see what files perl.exe was accessing during a scan. I am assuming that this has been corrupt for quite some time and that something has changed with the scanning process/GD that now causes perl.exe to crash on this file, as this artwork has been present for a long time on my hard disk (date last modified two years ago).
(In reply to comment #1) > I am assuming that this has been corrupt for quite some time and that something > has changed with the scanning process/GD that now causes perl.exe to crash on > this file, as this artwork has been present for a long time on my hard disk > (date last modified two years ago). Yes, a recent change to the artwork scan is to pre-cache thumbnails by resizing every cover in several different sizes. To the developers: Is there any chance that errors during the artwork scan can be trapped and ignored, rather than crashing the scanner? A single corrupted image file shouldn't cause a crash. We see a lot of forum posts where someone has an incomplete library of thumbnails when browsing albums. I'm almost certain that crashes like this are the cause. The user never knows that the scan didn't actually complete, since everything except the artwork phase completes without issue.
I will fix it to ignore corrupted files.
Should be fixed in change 15592. The log you posted is just a warning message, but I've added code so the pre-cache phase shouldn't crash if it can't resize something. Please test.
Created attachment 2722 [details] jpeg artwork file causes scanner crash I have found another case where a jpeg file causes the scanner process to crash.
well, gimp doesn't like the image. claims it's corrupt and will ignore the header: premature EOF and an extra 10 byes before header.
The image is fine in Windows, and opened fine in Photoshop Elements 5. I saved the image back out from Photoshop Elements and the scanner no longer crashes.
It opens fine in Gimp too, but the warnings are helpful as there is something clearly wrong even when just looking with a hex editor. The trick is finding the place to trap the problem, as it seems that perl crashes with no specific error just by accessing the image data.
problem line is Web::Graphics 251: my $origImage = GD::Image->$constructor($imageData); Even wrapping this in an eval brings no safety. It's a crash from inside GD.
*** Bug 6780 has been marked as a duplicate of this bug. ***
I came up with 2 possible workarounds (well, really just one): 1. Use the Image::TestJPG module which correctly detects this file as invalid. Unfortunately, I can't get it to compile on win32 and it doesn't seem that anyone else has either since I can't find a ppm. :( 2. Use the Imager module to read and then rewrite all JPG files on win32. This module handles the bad file fine and creates a new JPG that GD has no problem reading. The Imager module is upwards of 1MB to include. This method will also degrade the quality of the images, but I'm not sure that's a big deal. There are a handful of pure-perl image modules but none that detect the file as bad.
Probably relating to the crash, I have also noticed that my playlists were missing, probably due to the aborted scan. I tried to rescan playlists only, but it didn't seem to re-load the playlists into SC. I had to do a full rescan to restore the playlists.
Andy: Can we use Image::TestJPG for 7.0 on the platforms that it works on and then try to get it to build for Windows in a subsequent release? Also, what's the compile error? Maybe we can get some help on that...
This bug is only present on Windows because of our older libgd build, I would not include either of these worksarounds on other platforms.
Ok. Then let's punt to 7.0.1 for fixing the windows library. FWIW, the module just asks libjpg to decompress the image and relies on its graceful handling of errors. GD should do exactly the same thing, once we get it built for Windows. Have you asked on the Activestate list for help on this?
I still think we need a workaround for 7.0, as we currently segfault during scanning with no way of knowing which image is bad. The Imager workaround seems best, since it won't result in other bugs like "My corrupt cover art isn't being displayed". We should be able to get a new GD build they release 2.0.36.
Workaround using Imager checked in as change 16857. Moving target out so we look at this again when we can get a newer GD build.
Just to be clear: If you are still seeing crashes during the scan, we need to know about it. This bug remains open for 7.0.1 to optimize the image processing.
*** This bug has been marked as a duplicate of 4699 ***
why is this a duplicate? is the file not corrupt? is it 'exif' data as in 4699 causing GD to crash? i'm just curious.
Both bugs are about GD crashing on bad JPEGs, how is it *not* a duplicate?
This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1 Please try that version, if you still see the error, then reopen this bug. To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html
Reduce number of active targets for SC