What's the minimum effort core re-scans embedded metadata?

Can someone explain what’s needed to make the core/library re-read embedded metadata?
I modified a couple of things.
If I do replace small cover art by high res ones, a re-scan album or even a library rescan does the trick.
But If I have an album where embedded pics are all right and I only corrected the embedded genres only I found no way to make roon update.
Re-scanning that single album fails aswell as starting a complete library rescan.
Looking at file level, both on roon and fileexplorer shows the misery.

Unbenannt

My import setting are ‘genre prefer file’ but re-scan seems consider to note take that into account?

Help appreciated

Hi @StefanB ---- Thank you for the report and sharing this observation you have made with us. The insight is greatly appreciated!

Moving forward, to help aide in our evaluation of this behavior you are experiencing may I very kindly ask you for the following:

  1. Please provide a brief but accurate description of you current setup using this link as a guide. Please be sure to verify where your musical collection is being stored/accessed from.

  2. Please verify how you are editing your files? Furthermore, when you are performing these edits is the modification time changing?

-Eric

@eric
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)

Stefan