Best practices when combining storage trees?

Support
1

Apologies if this is already well documented and I’ve missed the answer, but I haven’t managed to find a clear treatment of this case.

When I look up how to avoid losing metadata edits, playlist membership, favorites and the like associated with tracks when the location of those tracks changes (whether because of file rearrangements or because of a move to a different Core machine), it seems clear that the right approach when a subset of files represented by a monitored folder in the Storage settings section is to move, you try to:

  • Disable that folder under Storage
  • Move the underlying files
  • Edit the watched-folder entry to point to the new place that track subtree lives
  • Re-enable it.

…and I’ve found that if the subtree underneath the moved folder in question remains the same, and I follow these steps carefully, all the metadata stuff associated with the tracks in that subtree does indeed appear to stick with the tracks as hoped.

But what if you’re coalescing subtrees? What if, for Historical Storage Reasons, you had multiple go/no-go areas of your music’s storage area – some places reserved for storage which you didn’t want to have indexed – so you ended up with multiple parallel watched-folder entries. Like five or ten, even.

And what if for a later RoonServer hardware incarnation you turned all those fiddly watched folder rules into the rules you use to copy tracks from your original track repository to local storage on the new Roon Core machine, such that the new Roon server’s storage has no no-go areas. Then, with this new tree in which everything beneath a certain point is eligible for indexing in Roon, you could conceivably have just one watched folder entry under Settings, that watched folder being the top of your new storage tree.

But that single watched folder would include all the stuff which used to be under a number of different watched folders.

Will this confuse RoonServer?

So far, I have a new single clean storage tree on a new RoonServer instance, but I’ve slavishly re-created all my old watched folder entries within that new tree – except now, taken together, they cover the whole new tree – just because I’m afraid of having Roon lose track of which tracks/albums are already known.

First: Am I right to be afraid?

Second: If so, is there a technique for combining tree watched folders without losing the already-known files’ identities?

Third: Am I correct in assuming that multiple parallel watched folders in the same filesystem are less efficient from Roon’s point of view than a single top-level watched folder per filesystem?

2

Earlier on yes, but Roon has improved its capacity to recognise albums through shifts in storage location. Taking a backup of the database before making any extensive changes is obviously still a prudent precaution.

The main thing when shifting music files is to not let Roon see two copies of the file at the same time. When that happens Roon could create a new entry for one of the copies, which may not have existing edits etc. This is the principle behind the method outlined above for moving files.

In the case of merging seaparately watched folders into a new single watched folder location I would proceed as follows:

Disable the separate folders.
Close Roon (May not be necessary, but I usually do it).
Move the files to new location.
Start Roon and enable new location (if not already enabled).

Roon will scan the new location and should recognise the files as existing Albums etc. You can then delete or retain the previous separate folders (now disabled) as you wish. I would do it one folder at a time, just to avoid complications.

Yes, but the difference shouldn’t be noticeable on a modern CPU until you had a relatively large number of folders (depending on their size).

3 Likes