Bugzilla – Bug 2542
rescan not finishing?
Last modified: 2008-09-15 14:39:24 UTC
When doing a rescan for new music adding 2 cd's I noticed the server still showing 30-40% cpu usage 1.5 hours later. Normally the server shows less than 1% cpu when idiling. I stopped the server. I have noticed this before and did a complete re-install of the server. I am not sure if the server was still scanning for music or stuck in a loop but I could hear the ex fw drive that the music is on being continually accessed. Mac os 10.4.3, itunes 6.0.1, ss 6.2.0, 13,000 tracks on ex fw drive, using itunes. Plugins : superdatetime and lazysearch2.
check the logs with d_import checked. please try latest 6.2.1 builds. note: known bug w/ lazysearch2 is problematic with a 'look for new and changed' rescan. workaround is to do a 'clear library' rescan.
Thanks I'll give the debugging a shot and I'll use clear library rescan method for a while.
I am pretty sure this is caused by lazysearch2 (r43) plugin, I removed the plugin and the server scanned fine (1 hour), after replacement and a wipe/scan and waiting for 3 hours the scan was still going.
I've put a comment about this in the plugins forum: http://forums.slimdevices.com/showthread.php?p=66224&posted=1#post66224 From the description in the forum (which referenced this bug) it does sound like a conflict between my plugin and SS, rather than a bug in SS. My guess would be the modifications that the LazySearch2 plugin is making trigger a rescan through the iTunes plugin, but I've asked Steven to try a couple of things which should say one way or another.
I've had some discussion with Steven and I think I've got a fix for that. I'm not sure if the scan was never finishing or if it was just very, very slow. I think the reason was that during the 'lazification' of tracks I used a track object to modify the TITLESEARCH attribute then 'update' it. That 'update' caused the core slimserver to check if it had changed and re-read the tags, and this appeared to be taking some time. As it's never going to change any tags on the actual file I don't think that re-scan is necessary and so I've swapped to using lightweighttrack objects instead. That seems to successfully prevent this problem. I'll roll that into the next version of the plugin and announce that on the PLUGINS list when it's done. I think this bug could be marked as closed (or similar), since it looks like it's not a SlimServer bug at all.