roon 1.5.339 x64 on Win10x64Pro
core 1.5.339 x64 on synology
bridge 1.0.164 on pi3b & kali & piano2.1
bridge 1.0.164 on pi3b & miniboss
collection sits on the nas
q2 nope all filedates remain untouched since there’s too many software I need to utilise besides roon which would start some senseless actions upon filedate changes.
Clever software does use hashes/checksums … but this could be rarely found.
mp3tag for example is fast since it doesn’t rewrite files or tags but utilises the so called ‘padding area’ which allows to modify/add content within the metadata tag by simply overwriting existing bytes which is dead fast. If you add content, the size of the remaining padding area gets smaller. If it’s too small, it then must rewrite the tag and the result will be a larger filesize.
Wrong pure guess I’d say that this happened when I added cover art, while when modifying genres (means removing some of the multiple genres) what happened was that the padding area did grow by some bytes.
But no problem at the moment, I switched from ‘Prefer roon…’ into ‘Prefer file…’ for genres …and I think this caused a complere re-read as it was done one the initial import. Or it was because of also having switched album art to ‘Prefer File…’ Did both at a time … took a while … now everythings fine (genres and album art)