I've seen similar things over the years ( extra albums etc ). I think some of it are pure bugs and some of it are down to the mechanism used to detect changes . And I think some cleaning up inmthe dB does not work properly either ?
I think LMS mainly uses the timestamp, but some of us including me try to not change timestamps while tagging to nut bungle the new music list . Then I *think* LMS tries to determine if the file size have changed, but some files have padding in the tags areas so that if you change the tag the file size do not change at all . A large enough change may be detected ? Some have written scripts that move the date a couple of seconds to get this to work better . I think I'll vote on the bug , you can surely find even more cases then you have described . So a catch all bug for better detection of changes is good . But how to improve if neither date or file size have changed ? I have one idea to go forward if LMS can detect that at least one file in an album have changed, discard all data on that album and rescan all the files in the album including cover art file . If the user have a reasonable organisation of the music LMS could even detect if anything in the folder with the album have changed size or something else ? Can the host OS provide info on file activity ? I'll bet Linux or osx can , so at least a simple mechanism for these OS can be designed ? ------------------------------------------------------------------------ Mnyb's Profile: http://forums.slimdevices.com/member.php?userid=4143 View this thread: http://forums.slimdevices.com/showthread.php?t=95222 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
