>i think i like the two phase idea... > >not having to do a full clear and rescan to change options is to me, an >absolutely long overdue MUST! > I think you misunderstand a bit still. If the user changes some fundamental options, the database could be recreated from a database that holds the raw tag data instead of reading from the files, but it would still do a clear and rescan, as far as the user is concerned. i.e. it would need to stop playback, clear the library and the current playlist, and rebuild it.
Potentially, it could create a new DB, leaving the old one in place for playing music until the new scan was complete, and then replace the DB (which would lose the playlist, etc). >...and also it sounds more safe and fullproof. Not really safer/fullproof. The process of interpretting tags into a format ready for browsing as a music library is the same; it's just the source of the data tags that is different. In one case, it reads tags from file, in another case it reads the tags from a cache. In fact, I'd say less safe, because there's more chance that out-of-date data would be used. i.e. it would be possible to change the library format by changing options and using the cache without scanning files on disk. if a file had been removed or changed, the change may not be picked up in the cache. It would depend on the mechanisms for deciding when to update the cache. > any system where you have to try to catch all these so >called "fringe cases" is to me, an inherently flawed system; how would >you know you actually caught every possible permutation? > Agreed, but it's how almost all media servers work, due to the time a pain involved in a full rescan. eg. iTunes only allows new music to be added, and changes to tags aren't picked up until you play the file. Similarly, MusicIP will look for new/changed files, and has a Refresh option to find orphaned files. These partial rescans apply changes to the existing library, there is no built-in functions to clear and rescan (although I guess one could find the library file on disk and delete it and add the root music folder to cause a rescan). A full rescan would lose any persistant data (eg. iTunes and MusicIP ratings, play counts, last play time). >i don't see why you wouldn't do it like that? if only one file is >"different" in the tag somehow, couldn't you just update the one album >record in these SBS tables without re-doing the WHOLE table? > How is that different to the current scan for new/changed files mode? _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
