Bugzilla – Bug 12311
scanner can't be stopped
Last modified: 2011-05-27 06:20:02 UTC
in order to abort a scan we now have to kill the process. The CLI command "abortscan" doesn't work any more.
Moving all SQLite-related bugs to 8.0.
SQLite bugs need to go back to 7.6 target.
I fixed this yesterday. r32240
Alan, are you also making sure the progress table in the DB is also being cleared after you abort the scan? I've seen a lot of scenarios in 7.6 where it's never cleared and it prevents further scans from being launched.
Hmm, it worked with my initial testing but seems broken again now.
Yeah, something is going on. If I abort a new & changed scan from the web UI it immediately shows the message 'The server has finished scanning your music collection.', but it appears to continue scanning.
Cannot reproduce this on 7.6. Will review with the team if need to close. Once scanning, if the "abort" button is pressed, the scan is aborted.
Jim - I can't reproduce this either (testing in onebrowser). How do you see it continue? Are you testing on trunk or onebrowser? Nightly build or from the source? Windows or something else?
Windows, onebrowser source from SVN, running as a Windows service. To reproduce, for me anyway: 1. Start with a new server, music folder pointing to my 32k track library, located on a local drive. 2. Start the server. A full scan using the external scanner is automatically launched. 3. Abort the scan. This kills the external scanner process, and the web UI's scanning progress says that the scan has finished, but the total time continues to tick. 4. Launch a 'new & changed' scan. I can verify that this launches the internal scanner, as there isn't a new Perl process launched. 5. Abort the scan. Again the web scanning progress says "The server has finished scanning your music collection." (And the 'Abort' link is no longer present.) But the 'Scanning new files' pass continues to count up, the progress bar moves, the time for the pass continues to increase, the file being scanned is continuously updated, total time continues to increase, etc. Browsing albums in web UI I can see the track and album count increasing. Going back to the Basic Settings page, the rescan drop-down is _not_ grayed out. If I stop and restart the server at this point (before the scan finishes), the new & changed scan does not appear to be run again, but the times for both 'Scanning new files' and Total continue to tick. Launch another 'new & changed' scan, abort it, and I get the same behavior - the scan continues to run.
> Windows, onebrowser source from SVN, running as a Windows service. Can you reproduce the same behaviour with a regular build? We do have some code to deal with the different ways of running SBS on Windows. But your setup is even more exotic (running perl as a service) than running perl from the command line. I wouldn't be surprised if there was an issue related to this. I'll verify the Windows build as a service once more.
Running the nightly build 7.6.0 r32434 from 19-May-2011 as a Windows service, I see exactly the same behavior. I have all other SBS servers on the machine stopped, so SqueezeSvr.exe (plus SqueezeTray) is the only thing running. I also managed to get this one into a state where it refused to run a clear & rescan, but it did run a new & changed scan. Just some more weirdness.
I think the remaining issue we're seeing isn't "scanner can't be stopped", but "server doesn't know scanner has been stopped". The scan process is indeed stopped, but the server doesn't update the progress information with this piece of information. Thus it keeps on counting up the time etc. That's not what the bug initially was reported for.
== Auto-comment from SVN commit #32468 to the slim repo by mherger == == http://svn.slimdevices.com/slim?view=revision&revision=32468 == Fixed Bug: 12311 Description: when aborting the scan, don't kill the scanner process, but rely on the ABORT flag. Then make sure the scanner cleans up behind. Please note that when the scan is aborted, it might take a few seconds before the scanner actually stops running.
Will retest with build 32468. If original bug is confirmed fixed, will close. If additional bug needs to be opened, it will be.
(In reply to comment #12) > I think the remaining issue we're seeing isn't "scanner can't be stopped", but > "server doesn't know scanner has been stopped". The scan process is indeed > stopped, but the server doesn't update the progress information with this piece > of information. Thus it keeps on counting up the time etc. That's not what the > bug initially was reported for. I think you could be wrong. Why else would the *file and album counts* continue to increase, not only as indicated on the progress page, but also within the browse views? I understand how the timers work and why they continue to count up. I'll try the proposed changes.
Ok, I fixed the abortion of the external scanner (clean scan), but the update scan still can't be canceled.
== Auto-comment from SVN commit #32479 to the slim repo by mherger == == http://svn.slimdevices.com/slim?view=revision&revision=32479 == Fixed Bug: 12311 Description: fix abortion of scanner in main process
Please note that after hitting the Abort link it might still take a few seconds for all async process to be stopped.