Bugzilla – Bug 3892
SlimServer initiates clear/rescan on its own
Last modified: 2008-09-15 14:39:24 UTC
I shut down SlimServer and SVN'd to r8875. Upon restarting a clear/rescan began running immediately.
Created attachment 1405 [details] log
http://forums.slimdevices.com/showthread.php?t=26188 not actually seeing this myself, linux nor win2k
Just happened to me again. I shut down the server, did an SVN update to r8880 and then restarted the server. It immediately started a scan. Since reporting the issue in the forum thread, I've restarted the MySQL service and even rebooted the machine, so I would think that if it were a state problem within the database, then that should have been cleared. Environment: Windows XP Pro server with Perl version of SlimServer 6.5b1, r8880 using ActiveState Perl 5.8.7. External MySQL 5.0.21 run on the same server. SlimServer run as a service using srvany.exe and installed with instsrv.exe from the Windows Resource Kit.
This happened again today. After having run and completed a clear/rescan I restarted the server. Upon startup, SlimServer cleared the library and began rescanning. The thing that's noteworthy about this incident is that it failed to find any artwork in that scan. I'm thinking now that whatever is going here on may be closely related to bug 3896. Will do more testing with --d_import --d_sql --d_mysql switches and then with the built-in MySQL server.
Are there any debugging option(s) that can tell us exactly who/what _initiated_ the scan? If there aren't, I'd like to suggest logging this information. Doesn't seem there are too many possibilities: from the web ui, run independently, or because the server thought there was any empty database.
Subject: Re: SlimServer initiates clear/rescan on its own Yes - that's pretty easy to do.
Created attachment 1457 [details] Log with --d_import --d_scan --d_sql enabled From the attached log, it looks like SlimServer thinks the tracks table is empty, so it does a wipe/rescan. This is now happening every time I start up the server (I'd swear that it seems like enabling the debugging switch -d_sql itself has an effect on it). There's no way COUNT(*) should have returned 0. I can only think maybe the query failed or timed out for some reason, but that isn't shown in the logs. If it does fail, should the correct action be to immediately launch a clear/rescan? Seems dangerous. I'll try next running with the built-in MySQL and seeing if I can recreate the problem there.
Ok - sounds good. I assume that after you stop slimserver, and do a select count(*) from tracks, there is a > 0 number in there?
Created attachment 1461 [details] Log from normal scan that wiped the database (In reply to comment #8) > I assume that after you stop slimserver, and do a select count(*) from tracks, > there is a > 0 number in there? Yes, there is. Here's the log from a related problem I mentioned in the forums - launching a normal scan wiped the database. I don't see any SQL to clear the tables, but you can see all of the INSERT statements being done. No artwork pass was made after this scan, so I have no artwork references in the library. I see that the ID columns were all reset, so the new data begins at id=1, if that's worth noting.
Jim - would it be possible to get a RDC or VNC login to your machine to debug your issues?
Dan, you can do that, but I'd like to do some more troubleshooting first. I've switched back to the built-in MySQL and so far I'm not seeing this problem with that server. I've restarted the server a number of times and it hasn't started a rescan. The problem may well have been with the config of the outside MySQL server. Prior to switching back to the included MySQL server, I did a reinstall of MySQL (downgrading to 5.0.18, just in case the problem might have been a library incompatibility with 5.0.24), trying to make the installation as plain vanilla as possible, and I still had the problem. Haven't had a chance yet, but I'd like to go through and compare the config files from the two installs and see if I can find anything obvious. The outside MySQL is still running on the server, so it should be easy enough to switch back and forth.
Ok, well it's good that it works with the built-in mysql. But I'm confused on why your clean install MySQL doesn't. FWIW, I'm running an external mysql on a Debian box, and I don't have this problem.
Fixed in change 9218 Thanks Phil!