>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. In what would would that provide benefits? If a file changes and is detected by SBS and it applies it to the music library successfully, what are the benefits in having an interim database that holds the tag data from the file?
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? It would mean much longer times to add new music. 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. I think the only benefit of the cache DB would be if options are changed to do with how tags are to be interpretted, in that it wouldn't need to re-read tags from files. But those options don't change often, so I don't see it as a big deal. If the options were clearer, and users could clearly understand what option they want to choose, then there would be less of a problem. Unfortunately, even though there have been some agreed suggestions for relabelling options to make them clearer, the bugs haven't been processed. _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
