Philip Meyer;578348 Wrote: > >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).
that was my understanding actually, sounds good to me. perhaps current playlist itself could be a second, separate DB and operate the same way? Philip Meyer;578348 Wrote: > > >...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. 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. even if it isn't true, i still think its more safe and fullproof, b/c as erland points out, any fault in the display of info, (outside of file tag / cache disagreement) would be in the SBS logic. (a user could be told keep the cache fresh/up to date after changes; not much different from current implementation) in any case, you wouldn't have to catch all the "fringe cases" Andy is trying to find. Philip Meyer;578348 Wrote: > > > 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'm not sure of the point here...? SBS shouldn't use a two phase system b/c itunes doesn't? i'm not seeing the argument against it, if thats what you're making, as compelling. i see large benefits to it, and i see important, yet surmountable technical issues to overcome, but i see no reason not to do it. the full rescan issue of losing stats and so on, hopefully can be overcome by making the files trackable, so in your example, when the current DB becomes the "old" DB after a rescan, the stats and so on cound track and be tacked on to the files at the new DB, before the old DB is deleted. Philip Meyer;578348 Wrote: > > >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? well this is something i might well have misunderstood. it sounded to me like andy was saying in an earlier post, what if only the RG album tag was different, you'd have to update whole tables for album records even if other album files were unaffected or something like that. so i was saying couldn't the update be parsed to just the album in question in the table, rather than redoing the whole table? or at least, i think thats what that was about, i've kinda lost context on that point. -- MrSinatra www.lion-radio.org using: sb2 & sbc (my home) / sbrec & ipeng (parent's home) - sbs 7.5.2b - win xp pro sp3 ie8 - p4(ht) 3.2ghz, 2gig ram - 1tb wd usb2 raid1 - d-link dir-655 - 43k+ mp3 ------------------------------------------------------------------------ MrSinatra's Profile: http://forums.slimdevices.com/member.php?userid=2336 View this thread: http://forums.slimdevices.com/showthread.php?t=82096 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
