Bugzilla – Bug 608
Scan 100% processor
Last modified: 2008-12-18 11:51:59 UTC
Windows XP. When I use builds 2004-10-03 or 2004-10-04 and I wipe the cache and do a rebuild the processor jumps to 100% and even after 2 hours the scan will not complete. Whilst it is scanning, after a few seconds the .db file stops growing, the hard disk stops churning. If I use --d_info and --d_scan, I can see the log file stops growing after a few seconds. On build 2004-10-02 and all prior versions this does not happen. If I wipe the cache (or delete the .db)and start a rebuild, the processor stays at 30% max and the rebuild is complete after 3-5 mins. I have 5000 songs. I will attach two logs which show where the scan stops - even though the processor remains at 100%. The other on the prior build showing that it gets past this point. I can see no differences in the log.
Created attachment 169 [details] Log showing where scan stops on latest builds
Created attachment 170 [details] Log showing that scan is OK on builds 2004-10-02 and earlier I stopped this after a minute or so, but it shows that the scan continues past the point where the lastest build scan stops
if you temporarily remove all the songs from ABBA Gold from your library, does it scan? each time it stops, try removing that one song from the library temporarily until it gets through. then you'll have a folder full of files that it gets stuck on. One of those files may be useful to Dean to test this problem.
I'm seeing exactly the same problem. I have about 5000 FLAC and MP3 files, but no WMA files (so the problem isn't confined to WMA files). I think this is a fairly serious bug, because on my PC (running Slimserver as a service on XP SP2), my Squeezebox loses its connnection as soon as Slimserver hits 100% processor load. The only way to get things going again is to restart the Slimserver service, which only works until Slimserver starts to rebuild its cache again.... Like Stuart says, the 2004-10-03 nightly shows the problem, but 2004-10-02 works fine.
Created attachment 173 [details] This file on its own causes 100% processor I've tried lots of other files on their own and this one causes the 100% problem
good file. for the record, here's the CPAN debug output: Working on an ASF_Header_Extension_Object: nextObjectGUID: [7C4346A9-EFE0-4BFC-B229-393EDE415C85] nextObjectName: [ASF_Language_List_Object] nextObjectSize: [39] nextObjectGUID: [44231C94-9498-49D1-A141-1D134E457054] nextObjectName: [ASF_Metadata_Library_Object] nextObjectSize: [374] ASF_Metadata_Library_Object: 0 name = WM/MediaClassPrimaryID value = D1607DBC-E323-4BE2-86A1-48A42A28441E type = 6 data_length = 16 ASF_Metadata_Library_Object: 1 name = WM/MediaClassSecondaryID value = 00000000-0000-0000-0000-000000000000 type = 6 data_length = 16 ASF_Metadata_Library_Object: 2 name = WM/WMContentID value = 0B347A08-605F-41B0-9FB5-0251F617A13D type = 6 data_length = 16 ASF_Metadata_Library_Object: 3 name = WM/WMCollectionID value = 7A48D370-0018-4463-B394-2EE4A3E91809 type = 6 data_length = 16 ASF_Metadata_Library_Object: 4 name = WM/WMCollectionGroupID value = 7A48D370-0018-4463-B394-2EE4A3E91809 type = 6 data_length = 16 nextObjectGUID: [00000000-0000-0000-0000-000000000000] nextObjectName: [ASF_Unknown_Object] nextObjectSize: [0] nextObjectGUID: [00000000-0000-0000-0000-000000000000] nextObjectName: [ASF_Unknown_Object] nextObjectSize: [0] nextObjectGUID: [00000000-0000-0000-0000-000000000000] nextObjectName: [ASF_Unknown_Object] nextObjectSize: [0] nextObjectGUID: [00000000-0000-0000-0000-000000000000] nextObjectName: [ASF_Unknown_Object] nextObjectSize: [0] nextObjectGUID: [00000000-0000-0000-0000-000000000000] nextObjectName: [ASF_Unknown_Object] nextObjectSize: [0] ...loops here for good. I'll fwd to Dan and see if he can fix it.
adding this at line 508 of CPAN/Audio/WMA.pm seems to alleviate the problem: last if $nextObjectSize == 0;
Dan checked in a fix for WMA files. Try tomorrow's nightly and we can close this off if all is well again. if it still presists, please try to find the exact file again.
Great!! Scans now back to 30% and 5 mins Thanks!
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.