Bugzilla – Bug 2792
rescan appears to do nothing but wipe library
Last modified: 2008-09-15 14:39:24 UTC
While trying a playlist only rescan, I noticed that d_scan d_import were showing no information. I then tried a full wipe cache and rescan. This resulted in d_import showing a wipe of all table, but still no scanning. The status now reported 0 artists, 0 songs and showed no information, no playlists. The was still no activity from d_scan, and no scanning. Restarting the server, a scan began on startup (presumably due to finding no data). This is recent, within that last week as I was doing a lot of rescanning tests last weekend, and earier this week. My initial suspicion is the recent changes in Control::Command
it appears that the rescan commands all check stillScanning, and do nothing if true. This breaks the earlier changes to allow scans to restart if retriggered (bug1623). They are now uninterruptible.
ok, this may only be a stillScanning issue. After the full scan, playlist scan trigger seems to work. i can only guess that there must have been something lingering that prevented it before. however, there is still an issue of not being able to interrupt a scan, yet clearly i was able to do the wipe library part, but not proceed into scanning.
I've been seeing this same thing for the past couple of months. I always do a full clear/rescan everything. I'd guess about a third of the time the scan will come back almost immediately with 0 albums, 0 tracks, 0 artists. Doesn't matter how many times you retry, it always comes back with zeroes until the server is restarted. On restarting, the server immediately begins (correctly) scanning the library.
cc'ing fred on this one. This seems to have come out of the cli changes. prior to this, I had made changes to have a scan stop and restart if another "rescan" trigger came along of any particular type. the new CLI seems to block successive scans, only starting if !isScanning. I'm not sure what the design choice should be, but the interruptible scan was in response to an earlier bug report. If scans cannot be interrupted, probably need to block the wipes and provide feedback (simple showBriefly should do it)
I only added this historically since the rescan was behaving widly if interrupted. I am also not sure we want a rescan playlist to interrupt a wipecache, the DB state is going to be wild after that. Also the automatic rescan done by server under some circumstances should not be interruptible IMHO. The surest way is not to allow interrupting rescans, no matter the source or circumstances. I agree however the UI is a bit short in such cases.
perhaps even hiding the "rescan" setup group while scanning is in process. i can make that happen from the Setup.pm module, but of course this needs a UI decision from SD how to handle the wiping part, is another question. The !isScanning does prevent another scan, but the wipe happens before the check. of course, I also think that any atempt to play music during scan should show the "still scanning, please wait" mesage on the player :) (maybe with the total number of tracks so far, since a progress bar is difficult when you don't know what the total will be but users will have some idea via other tools)
Just had this happen again today. Running 6.5, r6934 on WinXP Pro with MySQL. It had been well over a month since it happened last, so I thought the issue had been resolved. I'm not sure I follow the conversation above, but I'm not running anything that uses the CLI, and I'm pretty sure I didn't restart a scan/wipe while one was already in progress.
I think we'll want to grey out (using javascript) the rescan functions if a scan is occurring. But have a 'stop' button or something with a big warning. At any rate - this doesn't seem to be a big issue right now, so we'll address it in the split-scanner branch (when that gets merged back to trunk)
I too am getting this issue. Brand new install on Ubuntu (Dapper) using the slim apt-get respository. Running 6.5b1 (SlimServer Version: 6.5b1 - trunk - Debian - EN - utf8) I can browse my music folder, but all the normal "browse artists" etc. items say that my library is empty. Very frustrating! Is there a reliable fix/workaround for this? Cheers, Jim
Jim, the 6.5 builds are unstable at this time. you should be seeing an error in the logs, or if not, run command line. Likely what you have is a crash in the new separate scanner process. There have been reports of this and we're all working on it (even at 1:30 am), so if you can manage to try the command line or check the logs for the crash message, that can add to data points. As it stands, this particular report is not really an issue any more (given the context in which I reported it). The scan does appear to run and interrupting with a wipe doesn't really cause a problem since the scanner commits along the way and adds music. However, I think Dan's idea is a good one to keep open, so perhaps this is as good an issue as any for keeping this open.
The bug as reported is fixed in 6.5/trunk Any Setup changes should be additionally reported as part of bug 3267 (I've added the greying out suggestion already)