Bugzilla – Bug 17479
Aborting a wipe scan doesn't kill the external scanner process
Last modified: 2011-08-22 12:56:01 UTC
Created attachment 7408 [details] Screenshot showing the scanner running This is an issue I've been able to reproduce with r33110 running on either MacOS X 10.5 and a QNAP NAS: If you launch a wipe scan and abort it a bit later (while it's in the file discovery phase, for example), SBS will just say "Progress information from the previous scan is not available." in the information page, and will somewhat release the lock (i.e. lets you launch another wipe scan), but it won't kill the running scanner.pl process. Get back a moment later at the information page, and you'll see the scanning progress happily refreshing (see attached screenshot) ! From the shell, I can easily see the scanner's still running: raoul:~ sphelep$ date; ps -ef|grep scan Sam 20 aoû 2011 19:17:46 CEST 501 10237 473 0 0:30.54 ?? 2:04.47 /usr/bin/perl /Library/PreferencePanes/Squeezebox.prefPane/Contents/server/scanner.pl --logconfig=/Users/sphelep/Library/Application Support/Squeezebox/log.conf --priority=0 --prefsdir=/Users/sphelep/Library/Application Support/Squeezebox --wipe --debug scan.auto=OFF,scan=ERROR,artwork=ERROR,scan.import=ERROR,scan.scanner=ERROR,plugin.musicip=ERROR,plugin.itunes=ERROR
Created attachment 7409 [details] Log from scanner
Created attachment 7410 [details] Log from server
Yes, I'm seeing this too on Windows.
Do you see this when canceling during the file discovery phase only, or at any point? I'm surprised this is unknown to me, because sometimes I trigger and cancel scans dozens of times every day. But then I'm mostly testing with a small collection, where the discovery phase is very short.
I'm able to reproduce on both the discovery and scanning phases.
^ Same here.
== Auto-comment from SVN commit #33136 to the slim repo by mherger == == http://svn.slimdevices.com/slim?view=revision&revision=33136 == Fixed Bug: 17479 Description: write conflict on db causes failure of scanner abortion. We no longer need to update progress on the server side, as we're sharing the db with the scanner. But the server must not try to update it either. This might have caused bug 17478 et al. too. To be confirmed.
The first attempt failed pretty badly. I aborted it during the discovering phase. The progress display showed 'Finished scanning', but the scanner kept running and the progress display for the scanning pass kept on going. So I killed the external scanner process. Then I attempted to run a new & changed scan, but it completed immediately without scanning anything. Then I attempted another new & changed scan. This time it ran, but it's scanning every file in the library. I suppose the abort must have left an empty database.
(In reply to comment #8) > I suppose the abort must have left an empty database. I take that back. I just aborted the new & changed scan and find that I still have a full library in the db. Don't know why it was scanning everything as new.
Second attempt was better. This time I aborted during the scanning phase and it did kill the external scanner. However, the progress display still shows the scanning phase as active, but with a file count that doesn't change.
> The first attempt failed pretty badly. I aborted it during the discovering > phase. > > The progress display showed 'Finished scanning', but the scanner kept running > and the progress display for the scanning pass kept on going. I bet if you had let it run a little longer it would have terminated. The communication from the server to the scanner isn't synchronous, but the scanner is polling the server for information. Thus there can be a delay of several seconds. And then I'm not even sure the discovery phase isn't atomic. It might take until after the discovery before the scanner terminated. Could you please give this another try?
Created attachment 7414 [details] Screenshot showing progress still running
(In reply to comment #12) > Created an attachment (id=7414) [details] > Screenshot showing progress still running Looks ok now, the scanner process exits on abort, but I can see the same thing as Jim: status is still upgrading on the info page (ie Total time increases, but nothing more happens).
Ok, let me work on this some more.
== Auto-comment from SVN commit #33139 to the slim repo by mherger == == http://svn.slimdevices.com/slim?view=revision&revision=33139 == Bug: 17479 Description: don't handle scanner abort on the server side when the external scanner is running. Reset progress information when user aborts scan.
== Auto-comment from SVN commit #33146 to the slim repo by mherger == == http://svn.slimdevices.com/slim?view=revision&revision=33146 == Bug: 17479 Description: don't show abort link if scanner is already aborting.
== Auto-comment from SVN commit #33147 to the slim repo by mherger == == http://svn.slimdevices.com/slim?view=revision&revision=33147 == Fixed Bug: 17479 Description: don't try to set the isScanning flag from the server when the external server is running. Let the user know that the scan has been aborted.
r33148 seems to have sorted out the external scanner, it dies gracefully and all the counts are OK. The internal scanner won't abort during the discovery phase. The time keeps increasing and the pathname is updated. From Michael's comments, I guess this is expected. Music Scan Details Discovering files/directories: /music (123404) Running 00:05:26 /music/P/Place4Tears - The Silent Flame/Keep_Me_Back_Album_Version_.mp3 The server has finished scanning your music collection. Total Time: 00:05:26
For obvius reasons, you cant have this bug in the 7.6.1 release it's very bad
can someone please define the difference between the "internal" and "external" scanner? what function does each serve that the other doesn't? does it have anything to do with sqlite/mysql?
Mike, the "external" scanner is what gets run when you do a "clear and rescan". It's a separate program, launched by SBS, although sharing a lot of the same code. The "internal" scanner is what deals with a "scan for new/changed", and it's totally within SBS itself. The plan is to get rid of the external scanner, one day, when all the other bugs have been fixed. :) Nothing to do with SQLite/MySQL, though.
Mikael: +1 Can't wait to see how this is explained to the sweaty, desperate, music-deprived masses who've been waiting weeks for this release! :)