Just a thought here: stopping the slimserver service would not necessarily stop a scan that is under way. Because we are in split-scanner territory, the service spawns a separate perl process to do the scanning. Stopping the slimserver service would leave the scanner process running. Starting the service again might spawn another scanner. Thus, the transactional deadlock. Then again, perhaps Dan has already put code in that checks to see if a scan is underway before launching a new scan. If you are running windows, use the free SysInternals Process Explorer utility to watch the server process and the separate scanner process. Otherwise, in linux, I guess it would be ps ax or something like that.
In terms of what caused the db wipe in the first place, there was a change to schema.pm checked in back on Friday. Might that have required a rebuild of the db? -- gharris999 ------------------------------------------------------------------------ gharris999's Profile: http://forums.slimdevices.com/member.php?userid=115 View this thread: http://forums.slimdevices.com/showthread.php?t=26188 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
