Philip Meyer;578009 Wrote: > I don't see that ever working efficiently; in order to look for > new/changed files, it would have to calculate the checksum on *every* > file to see if it was different to the previously calculated checksum. > Effectively, it would probably be quicker to do a full clear/rescan!
you guys would know all that better than me, altho i'm sure someone clever in these matters could figure out how to use the FAT tables or something like that to spot differences... but i agree with your next statement so i guess its moot anyway: Philip Meyer;578009 Wrote: > It should just be stated that for new/changed files scanning mode to > function, there is a requirement for modified files to write updated > file modification times. > > A scan for new/changed files should work on the files modified since > the last scan time. cool, that was my first approach. i don't understand why that info isn't enough for SBS? thats what i'm trying to get Andy's view on, so he can explain it. i've always not understood why that wouldn't be enough? Philip Meyer;578009 Wrote: > I think there's an issue that if separate artwork files have changed, > these files will only be found if the scanner detects a song file on an > existing album as changed. i.e. a scan for new/changed files needs to > also look for modification times on artwork files that could influence > an album. sure, makes sense. Philip Meyer;578009 Wrote: > e.g. another possible fringe case: a song file may move to another > folder, where there is different artwork. The original and new artwork > files may not have been touched since the last scan (modification dates > the same), and the song tags may not be different, but as the song file > is in a new location, it should look for a new artwork file. is only filename considered? i thought filepath would be as well? surely considering filepath would eliminate the issue? Philip Meyer;578009 Wrote: > I think there probably are many fringe cases where tags changed in a > file don't apply correctly to the SBS DB. In most cases, these are > unlikely to happen, but when they do, it's infuriating and may take a > new user a long time to realise that a full rescan would correct the DB > content. i.e. there's now nothing wrong with the song tags, but the DB > doesn't reflect that. yes, this is why i favor an approach where ANY file change causes SBS to delete that ENTIRE corresponding record, and create a new record from scratch for that file (and art). (then later, the erland plugin could match the stats and so on. but that problem should be fixed AFTER this one) Philip Meyer;578009 Wrote: > eg. if an album has a single song with a guest artist, and the ALBUM tag > for that song is changed, the song may be moved to be within the correct > new album title, but properties on the existing album may not be > corrected. e.g. it may still be considered a compilation, or have the > wrong album artist, etc. It's not that the scanner hasn't seen that > the file has changed, but that it doesn't apply the change to all > affected artists, albums, genres, etc. you lost me a bit here... bad tags are bad tags. if one file in an album changes, and its not in sync with the tags on the other tracks of the albums, i would never expect good results. what i would expect, is that the scanner reflected properly what it found in that one updated track. is this what you meant? if its necessary to have the scanner rescan whole albums due to changes in one track, so be it... i can live with that. -- 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
