Bugzilla – Bug 17240
Scanner randomly crashes whilst Scanning new files phase
Last modified: 2011-07-18 09:16:05 UTC
Running onebrowser branch, SVN revision 32427. I've been having trouble with the Scanner randomly crashing during a scan. I stopped the server, deleted all my .db files from the cache folder, and restarted. SBS automatically starts a scan, and shortly after starting the "Scanning new files" phase, the external scanner process crashes. It had failed after scanning 169 files. NT System Event Log contains: Application popup: perl.exe - Application Error : The instruction at "0x08ce4364" referenced memory at "0x05140023". The memory could not be "read". The last thing reported in my scanner log file was: [22:04:33.2188] Slim::Utils::Scanner::Local::new (635) Handling new track file:///M:/Music/Phil%27s%20Music/Ambient/Brian%20Eno/Another%20Day%20On%20Earth/07%20-%20How%20Many%20Worlds.mp3 That file is an MPEG 1 Layer III, ID3v2.4. Bitrate 224, 44100 Stereo. After the crash, I stopped the server, deleted the .db files again, and restarted. The scan failed again; this time on a different file - it had processed 2289 files before crashing. Every time I try, it fails at a different (apparently random) time/file. NB. Also, the Web UI Settings > Information Music Scan Details section reports that the scan has finished, but doesn't indicate that it failed/crashed. It still reports "Scanning new files", and the scan phase time and total time continue to update.
I set all scan.* log levels to debug and saved log settings. However, the external scanner process doesn't seem to pick up the log prefs - there's nothing particularly useful in there - just a single entry per scanned file, such as: [22:04:33.2188] Slim::Utils::Scanner::Local::new (635) Handling new track file:///M:/Music/Phil%27s%20Music/Ambient/Brian%20Eno/Another%20Day%20On%20Earth/07%20-%20How%20Many%20Worlds.mp3
I am having similar problems to those reported above. Scanner.exe crashes and Windows XP SP3 pops up a message - scanner.exe has encountered a problem and needs to close. We are sorry for the inconvenience. Please tell Microsoft about ...... There is nothing in the scanner.log file that is any help, it doesn't even tell what file it is up to. In fact after scanner.exe crashes, the SB Control Panel reports that the server is running. This has been going on for some time, but I found a clunky work around. By installing 7.6 r32108 I can complete a "clear & rescan", then when the scan is finished I just install a more recent version of 7.6. This thread http://forums.slimdevices.com/showthread.php?t=81952 mentions 2TB disk drives on XP as perhaps being a factor. I had my music on 2TB drives for some time without any problem using MusicIP, MP3Tag, Album Art Downloader and Foobar2000. It was only after 7.6 r32108 that SB Server had problems I usually download the 7.6 nightly on Saturday and try it out, keeping the previous version in case the new one has too many problems. I have replicated this problem on 5 different computers (2 test boxes, "production" HTPCs at my son's, daughter's and my house), all with 2TB disks and XP and the same music library. The hardware is quite varied, from Mini-ITX to uATX and ATX motherboards, using different AMD and Intel CPUs - the 2TB disks are either WD Green or Samsung HD204UI . The problem is not the music files or the cover.jpg files as scanner.exe from 7.6 r32108 completes every time. The problem is a change made to scanner.exe shortly after version 7.6 r32108. (see this thread http://forums.slimdevices.com/showthread.php?t=86802)
I have a 2TB HD, although the music is on a 1.38TB partition. Windows XP SP3.
Please take a look at bugreport 17240: "Artwork scanning fails when a clear & rescan has been initiated" too. https://bugs-archive.lyrion.org/show_bug.cgi?id=17240
I meant bugreport 17207: https://bugs-archive.lyrion.org/show_bug.cgi?id=17207
I am also having an issue with random crashing on the latest nightly beta files during a scan. The annoying thing is that it also stops the squeezebox server about half the time when the scanner crashes. It never gets stuck on a particular file. I tried going back to the production version of the software, but I still had issues with the scanner. I can also verify that once I used the 7.6 r32108 version of the scanner to do a new scan, I was able to get a complete scan without a single crash, and the server didn't stop after completion! I am not updating again until this gets fixed. Version: 7.6.0 - r32523 @ Thu Jun 16 02:04:34 PDT 2011 Hostname: HP-MEDIA-SERVER Server IP Address: 10.10.0.12 (this is the internal ip address) Server HTTP Port Number: 9001 Operating system: Windows Home Server - EN - cp1252 Platform Architecture: 586 Perl Version: 5.10.0 - MSWin32-x86-multi-thread Database Version: DBD::SQLite 1.32_02 (sqlite 3.7.5) Total Players Recognized: 2 Library Statistics Total Tracks: 100,398 Total Albums: 8,649 Total Artists: 2,403 Total Genres: 43 Total Playing Time: 6712:39:33 Please let me know if there is anything else I can do to help get this fixed.
Since my first comment (comment 2) I have found that simply copying the r32108 scanner.exe over a later version will allow a clear and rescan to complete. I was reluctant to do this as I thought that there might be environment variables or some other dependencies, but it appears that scanner.exe is stand alone.
Phil - if you run the scanner against the reported file (scanner.exe "07 - How Many Worlds.mp3"), would it sill fail?
(In reply to comment #8) > Phil - if you run the scanner against the reported file (scanner.exe "07 - How > Many Worlds.mp3"), would it sill fail? As I am running from Perl source, there isn't a scanner.exe. So the command I ran was: "P:\Programming\Perl\bin\perl.exe" -w "P:\Music\SlimServer\Beta\server\scanner.pl" --prefsdir "D:\Squeezebox Server\Beta\Prefs" --logdir "D:\Squeezebox Server\Beta\Logs" "M:/Music/Phil's Music/Ambient/Brian Eno/Another Day On Earth/07 - How Many Worlds.mp3" This worked fine on that file the scanner previously failed on, but like I say, every time I run a full scan, it fails on a different source file.
*** This bug has been marked as a duplicate of bug 17173 ***