Bugzilla – Bug 1623
Issuing rescan/wipecache when rescan/wipecache is in progress confuses server
Last modified: 2008-09-15 14:36:01 UTC
If a rescan is in progress, doing a rescan or wipecache confuses the server. Did not investigate too much, but stillScanning() returns false after the second rescan and the scan continues apparently (not always it seems). Checked in (3312) a workaround in Command.pm where rescan/wipecache code is not called if a rescan is in progress, but this may indicate a deeper problem to be investigated by the scanning/DB experts.
We should probably halt the current scan and restart a scan in the case that a new wipe or rescan call is made. (imagine the case where somebody adds a track, clicks rescan, adds another track and clicks rescan again, when their scan completes there's a good chance that their second track doesn't get discovered.)
all of the importers seem to takes care of stopping any existing scan when a startscan is called. However, Control::Command is checking isScanning before calling any global rescan. These were added by Fred intentionally a change 3312.
fred, Have you tried reverting 3312 and checking the same conditions any time recently? I am guessing this may be a race condition setting and clearing the importsrunning hash. I'll have to try it out.
Fred - any update here wrt KDF's question?
Did not have time to try this again since I posted the bug. I am not sure I will be available to over the week-end, but it is not diffult to test... It is quite important that it works for the first launch of the server. Initially, it starts to scan something (iTunes which ends up "on auto" on a Mac for example), then the user starts to change the preferences... and it should rescan but today it does not (because of my patch).
Thanks Fred, looks like it is still confusing the server, but I think I see why. I should be able to whip up a quick patch sometime today
Created attachment 718 [details] abort scans and allow new scan Rather than doing the entire doneScanning cleanup, an aborted scan needs only to clear the barest essentials to allow a new scan to commence. Calling doneScanning actually causes an race condition, which is the root of the prior confusion. This needs a bit more testing, and I'd welcome any feedback. I am on a very small library here, so I have only been testing with "rescan". There are still many combinations of pref-triggered rescans that should be verified.
Created attachment 719 [details] updated adds some more cleanup for resetting iTunes parser. Also flags d_import log messages with "Import: " as the start of text. Helps a bit with readability if it ends up in with something like d_info log output.
Looks good!
in trunk at change 3955. please re-open if anyone finds any problems with it.