>> - first rescan/wipecache request was executed
>> - later requests were ignored as long as a scan was running
>
> Was that true of automatically launched scans due to pref changes? I
> thought these always triggered a new clear & rescan, and that any
> ongoing scan was aborted.
This only happened in the web based setup wizard presented to linux users
upon first access to the web UI: as the scan was launched automatically,
it would kill that scan to start a new one if the audiodir pref was
changed. But on regular prefs changes running scans would lead to a new
request being ignored. From 7.6's wipecache call:
# if we're scanning allready, don't do it twice
if (!Slim::Music::Import->stillScanning()) {
>> - first scan is executed as always
>> - second scan would be queued for later execution, when first ends
>
> IF that second scan is a wipecache, is the ongoing scan allowed to
> complete?
Yes. We still don't automatically abort running scans.
>> - third depends:
>> - if a wipecache is in the queue: no scan is added
>> - if new request is a wipecache, it clears the queue and adds
>> itself
>> - if it's a rescan of all folders, dito
>
> When you say the queue is cleared, does that include the currently
> executing scan?
No. See above.
> Manually launched scans can't be queued, correct? The buttons are still
> disabled in the various UIs while a scan is in progress, so the user
> can't queue up multiple scans?
Hmm... that's correct. The UI doesn't allow this. Maybe we should change
this to only be blocked if a wipecache is running. But that's for post
7.7.0.
--
Michael
_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta
