Make Roon knowing the files by GUID (no matter what storage location and roon instance)

Roon does not change the files indexed but only collecting those in the DB. By moving and reorganization of folder locations one is always endangered to loose valuable information. Hearts, valuations, hidings, albums combined … playlists! Yes it is possible to do reorganization with instructions and in most cases it works. But if something goes wrong it’s over and information is lost if e.g. the backup is done on another server and new server setup works with new locations (then the backup has no value anomore). I believe everyone ever dealing with such things has experienced trouble there.

I suggest the following solution:

  • for each scanned file generate a GUID (global unique ID) and store it to the file (e.g. as tag)
  • Make the DB referencing to those GUIDs additionally to file & folder
  • roon needs to remember all sorts of “user decisions” based on this GUID

Roon would be able to identify each and every single file also after reorganization and indexing again to new storage locations. Tags, valuations etc. will never be lost again.

On NTFS, each file has an associated file ID, which is a 64bit number that doesn’t change for the lifetime of the file - even if the file is modified or moved. I wonder if Roon DB is already using that.

Roon’s stance on altering files is well established: they don’t do it. So adding a GUID tag to a file is not likely to happen.

Not all file systems that Roon encounters have file IDs that never change. Plus, you never know when I file will be moved from one file system to another.So…

Another way to identify a file without changing metadata or depending on the sytem would be to use a hash of the [uncompressed] audio data.

When you add a storage location, I believe Roon creates a storage ID and uses that.

thats true and would do the trick even better! So I’m wondering why roon is so sensitive and trashing relationships if I only rename folders or move it to another physical storage. In my eyes this is a real shortfall that can be resolved easily.

It’s not as easy as it seems. Without using filesystem-specific mechanisms, a folder rename will appear to Roon as a big chunk of deletes, followed by a big chunk of creates. You would need some heuristic way to match the files and figure out they just moved. That can be done simply by matching file name, size and time stamp, or through other mechanisms (e.g. hash). Whatever you do, it won’t be instantaneous, especially if it involves hashing content. The more files you move, the more time it takes. So, it will first look as a delete+create, then it will look as a move, and that could cause some confusion.