Bugzilla – Bug 2087
Rescanning too often.
Last modified: 2008-09-15 14:36:01 UTC
If I go to server settings and enter an invalid path for a music folder or change your playlists folder or language it begins rescanning automatically. It shouldn't.
Does a language change really start a scan? Can't reproduce this on 4209.
This might have been fixed yesterday, at change 4190. The defaults for the scan settings were wrong, and would trigger an onChange event since the whole page gets submitted whenever anything else changes (like language or paths). The path change, however, is likely still an issue. I think the onChange for that starts a scan regardless of the validity of a path.
Created attachment 808 [details] only scan if -d passes instead of unconditionally rescanning, only do it in the case that audiodir passes -d test
Michael: 4190 only changed the order which the rescan options were displayed. Kevin: That change looks reasonable, but we should also look to see if the audiodir and/or playlists dir have changed before triggering an automatic rescan.
isn't that was calls onChange? the dir being different? I'm not sure I'm following.
The problem is that any change to the page triggers a manual rescan, now that we have a pop-up menu for choosing the rescan.
so, the popup then go back to its own pref, say 'rescantype'. The 'rescan' button would then appear blow instead of beside (we dont have layout control precise enough to force two prefs into same line). Then ONLY clicking rescan would act on the popup setting. we'd have to suppress the change msg for rescantype to make it appear seamless.
Created attachment 810 [details] split prefs to avoid rescan this goes in addition to attachment 808 [details], as an example of what I have explained above.
Looks good. Go ahead and commit.
committed to trunk at change 4248