>>>>> On September 23, 2010 Phil Meyer <[email protected]> wrote:
>> my understanding is SBS is being redone to "constantly rescan" as the >> OS informs that changes were made to a file or file table, or something >> to that effect. assuming thats true, imo, better to use a 'tag cache >> table' for the benefits inherent in it. Right, Andy's already doing exactly the right thing - using the os notification system to detect changes to the music library and initiate incremental db updates and AFAIK that's working well. > Are you saying that you think its a good idea that when a single > file changes, SBS should read the changed tag data into a cache DB, > and then throw away the whole music library and recreate it from the > cache DB, because that would be safer/fullproof? I think a framework like this would be much easier to get "right". I'd hesitate to say *foolproof* because it still wouldn't make it trivial, and because of the connotation towards the developers. > It would mean much longer times to add new music. I think it could be made very fast by chunking the work and making many fewer, bigger commits to the db. This is probably the least certain part of the argument; I wish I had some time to mock up a proof of concept.. > It would mean no playback (if the DB is wiped) or playback at least > stopping (if a new DB is created and then replaces the original) > whilst scanning for new/changed files. You'd build a new db in the background while running on the old db, and swap at the next convenient time (maybe between songs). This would also make how long it takes to rebuild the db less critical. You'd have to map playlists, stats, etc to the new db, but I thought one or two guys on here were working on that? And anyway, that problem needs to be solved either way. Greg _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
