Background audio analysis: when?


I’ve changed my disk filesystem from APFS to exFAT (cause compatibility for a future ROCK). The mount point and directories has not changed: they are restored from another backup disk which is a 1:1 copy. Unfortunately, Roon Server started a new analysis of almost 54.000 tracks over 71.000 I have.

Now my questions is:
This kind of information (crossfeed, waveform, etc…) has not changed, they are the same tracks and they should be in the current DB. Whay Roon do a new scan (however not for all tracks)?
I think the file properties has changed (because the new FS) with a new file date as well, then Roon do a new analysis because it suppose a change?

Thanks for the clarification.

Best regards

Roon will perform a rescan and reanalyse whenever a file is changed. A change is anything that alters the file created or file modified time. Migrating your library from one drive to another will result in such a change. The only way around this is to use some form of bulk file change software that allows creation and modification dates of the new location to match those of the old location.

When Roon detects a file change it has no way of knowing what has changed. It could be metadata or it could be the audio file itself. This is why both a rescan a reanalyse are performed. In your case, rather frustratingly for you, nothing has changed at all!

I supposed it’s like that. Can I suggest a more reliable strategy? “Scan information” should be paired to a file checksum (like md5sum or sha1 and so on …). In this way Roon will recompute the information when the content is really modified (metadata or audio content). A change in date (or properties like permissions and so on) not concern necessarily a modification of the file content and a new rescan should be avoided.

Unfortunately, now is too late to revert the date because I don’t know the original ones anymore. :smiley: I hope I’ll avoid the rescan when I’ll migrate to ROCK using the same disk and current backup.

If you migrate the storage correctly to rock this should not happen. Just restore backup and edit existing storage path to point to rocks storage. It will look like it’s redoing it all but it doesn’t it will relink apl media and maintain all edits and play counts Etc when it finishes.

“A change is anything that alters the file created or file modified time” : If the files goes to another place (another path), is this a “change” also ? When we migrate from one drive to another, the root path, and so the file path, may change also (not same volume id or path for example), even if the file time stay the same.

I can only speak from a Windows point of view, but migrating from one drive to another always alters the file creation date, but leaves the modified date intact. Therefore, without bulk file changing software, always forces a rescan and reanalyse.

In my experience a change in path alone does not cause Roon to rescan and reanalyse. When I moved my library from the internal C Drive to an external SSD (D Drive, in my case) I used bulk file change software to ensure that Roon didn’t notice a change. I’m only able to do this because I have a rather “geeky” approach to the file maintenance on my library. I use bulk file change software to ensure that created and modified date always remain the same.

When I migrated from C Drive to D Drive the files on D Drive showed the correct modified date but a new (and thereby incorrect) created date. I used the bulk file change software to rectify this. So, when I pointed Roon to the new storage location, it didn’t need to rescan and reanalyse.

1 Like

may i ask what " bulk file change software" you used and was it for windows ?

It’s called BulkFileChanger. The current version is 1.72 and is available as a free download, from various sources. It’s for Windows only.

1 Like