JJZolx;530612 Wrote: > > I'm running a clear/rescan right now and streaming to three synced > players. This is possible since the SQLite method of clear/rescan > creates an entirely new database, then swaps it for the old one when it > finishes, unlike with MySQL. I don't know what happens at the point > when it finishes (I'll know in another 10 minutes), whether the music > stops when the new database is swapped in.
But, you see, that doesn't work on Linux. Both scanner.pl and the SBS itself modify the tracks_persistant database, collide on the lock, which kills off scanner.pl's scan, so it is not swapped in at all. The example above -was- with a full 'clear-and-scan' but I wanted to listen to music at the same time. This is no longer possible at all: at least with the old scanner, i could listen to what had been scanned as it came in... so I could wait a couple minutes and have something show up in the library. but now, any access to the library (or rather tracks_persistant) will kill off the scanner.pl process. Restarting SBS makes it find the incomplete scan, which it rejects and goes back to the prior state.. ie, in my case with the mistagged album still there. The way around it? rm /var/lib/squeezeboxserver/cache/squeezebox.db and restart the server, forcing a complete scan. > > I don't think the coordination between manual rescanning and > auto-rescanning has really been tested. Maybe it hasn't even been > implemented yet, since with TinySC, where auto-rescanning will be going > live soon, I don't believe there's any way to run a manual rescan. > On Linux with SQLite, it doesn't appear that scanner.pl is functional at all. (I used to have a nightly clear-and-scan, but would usually find the scanner had been left in a strange state, it would think it was still scanning for some reason... I believe you also noticed this a month or two ago.) > > I have been seeing some dropouts when streaming to these synced > players, and they always seem to happen about 12-15 seconds after the > start of a track for some reason. Sometimes when pressing play there's > a longish wait before a track will begin - a few seconds longer than > with 7.5/MySQL. I'm also seeing occasional slow searches and long > waits for browse album pages in the web ui. I think we could be > starting to see the limitations of SQLite. Most of the time it's just > as fast as with MySQL, but there's a lot more variability in response > time. Well in my case, the long pauses show up as both threads complain about a locked table... Seen that enough times in other things (a good old 'deadlock' condition) that I'm reasonably certain it's the lock waiting to timeout and giveup. not that it works at all after that point.. -- snarlydwarf ------------------------------------------------------------------------ snarlydwarf's Profile: http://forums.slimdevices.com/member.php?userid=1179 View this thread: http://forums.slimdevices.com/showthread.php?t=76850 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
