For once, I agree with MrSinatra! I generally dislike auto-detect changes in apps; if every app I have running did it, my HD would be doing nothing but churn all the time.
I prefer to scan when I know I'm not using the machine for anything else. I have an ordered sequence for ripping CDs. I scan to detect set of new albums after I have ripped, tagged, applied replaygain, added artwork, analysed in MusicIP, etc. If it auto-detected changes whilst doing those activities, it's likely artwork would be missed (long-standing SBS bugs with detecting artwork file changes); it might not detect MusicIP mixable status, or at least could end up scanning/requesting MusicIP several times until the status is present. There's loads of things that could end up in bad states/non-deteministic results based on order of scanning files. eg. if it only sees a few files for a new album, it might consider it not a compilation album, and then as more files are detected and the scanner is re-run, the album may now be a compilation. At best, its less efficient. It could result in incorrect music library content though. If a new album is scanned all in one pass, it's perhaps more likely to work cleanly. It's certainly more efficient to scan in one go, rather than frequently detecting changes and rescanning continuously in the background. I'm not sure how that works with SQLite anyway (scanner locks DB - needs to be unlocked to allow scan + playback?). Auto-scan once at startup is bad enough. On the other hand, MusicIP GUI auto-scan works pretty well. But then again, MusicIP server doesn't auto-scan (manual rescan via webUI only). _______________________________________________ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/beta
