Currently Roon chokes every time there is any kind of change in the directory structure(s) of a local library, and makes the tracks UNAVAILABLE, to the massive disappointment and chagrin of the Roon user.
I would say that there is NO REASON for Roon to do this. The expected and desired behaviour ought to be, after scanning the net shares and folders in the Storage section because there were changes, that Roon should do a pass/scan on all the playlists, and if it finds a MATCH between a song in the playlist (album, metadata, etc. - surely, Roon can do this!) and a song in the library.
Or perhaps it is not automatic, perhaps it is per playlist and user activates a menu action to fix a playlist.
I would like to hear the argument saying that “no, Roon cannot match a song in the playlist with a song in the library”. That would be absurd.
Finally, when a match is found, Roon must update the playlist so it does not show unavailable, and the user can play it.
This should not be hard! I think every Roon user would vote for this feature! And this should be the proper Roon design.
Thank you
P.S. The point I am making is that, even if the track/album changed location from one share/folder path to another, ultimately it does not matter. That song/album is in the library, Roon can find it, and compare it to the track in the playlist, successfully, then update the playlist. Not choke on it and destroy my playlist. This has happened too many times now.
What you describe Roon should already do … if it’s not then there is an issue.
Thus I’ve moved your topic to the #support section of the forum.
In order for Roon’s @support team to better assist you, please provide a brief description of your current setup using this link as a guide.
Make sure to describe your network configuration/topology, including any networking hardware currently in use, so they can have a clear understanding of how your devices are communicating.
Roon most certainly does not already do what it is supposed to do.
My router simply changed the IP address of the NAS where my music is. I changed the network share IN ROON accordingly to the new IP address. Right there, Roon should have handled this without a hickup. But instead Roon crapped out and marked all the tracks as unavailable.
How is that the proper behaviour of Roon?? The only way that I could recover is to
Put back the IP address the way it was before
Restore from a backup BEFORE the IP address change.
This is terrible. I have seen instructions where you have to do a bunch of thing in order for your playlists don’t get screwed up. But that is missing the point: we shouldn’t all be IT experts and Roon should handle this gracefully and automatically.
Therefore my feature request is legitimate and please put it back to the feature requests. This is way more higher priority than any UI changes that you are making and further confusing users.
Let me repeat the point you are not getting: the user should not be concerned WHERE the song/album files are. The only thing the user should have to do is add the new location in Settings → Storage. Everything else must be done by Roon to update the tracks in a playlist and NOT show them as unavailable. This is not current Roon functionality. This is the functionality I am requesting.
This is the last thing which is preventing me from enjoying my music with Roon. This is after months of recovering from all the changes in Roon Version 1.8.
I had someone whisper in my ear that whilst Watched Folders and the DB links to play the files are automatically updated this does not happen with Playlists.
For me (and I don’t speak for Roon of course), this sounds like a significant omission and do appreciate the frustration it must cause.
I’ll happily move your topic back to #roon:feature-requests but personally I view it as a bug.
First, let me walk through how this process should go:
When you’re moving your collection from one location to another (even if it’s just a path change), if you follow these steps, everything should work exactly as you’re hoping:
Basically, as long as the content isn’t imported twice (i.e. you have two paths entered in Roon at the same time), all edits, playlists, and more will sync back up. What happens is Roon scans the new location, understands that this is the same content as before, and will match up the database entries. This scanning process takes time, because it has to match all of the files up individually, but after everything has been scanned this should work for you.
Now, as to why it didn’t work for you here: Just to confirm, did you wait for the import / scanning process to complete at the new location? If not, it may have just needed time. If you did, then something definitely didn’t go right here and I’d be happy to have our team look into it further (though I don’t think we’d be able to learn much unless it happened again since the backup was restored).
One final note on this, is that if the IP address is not consistent, I recommend setting a static IP or using hostname to connect. The IP address in Settings > Storage does not change if that device’s IP address changes, so frequent edits (and time for everything to sync up, as mentioned above) will be required. This is definitely not the best experience, so making sure that the path is always consistent is the best bet.
But let me point out where the Roon bug is and how the burden could and should be shifted from the user to Roon. In the quote below, the problem is that Roon sees the music twice.
Roon could:
Instead of scanning watched folders in parallel, scan them sequentially. This would ensure that Roon does not see two copies of the music - please correct me if I am wrong.
Alternatively, why is Roon choking if there are two copies of the music? Your software developers can design a strategy that says: “if I am already seeing this music, I will ignore the second copy”, or “I am seeing a second copy, it must be an update, so I will replace the first location with the second copy location” or another strategy. But what it should not do, is choke on it, and choose NO COPY, and make the track UNAVAILABLE.
Both of the above can be easily solved in software. So call it a bug, or a future feature, but just fix it. The inconvenience by this problem is gigantic. If you can take a poll from Roon users, please do.
I listened to you and went to replace the IP Address with a domain name, and also to test your method.
Well guess what: it doesn’t work! I deleted the storage folder with the IP address. Then I re-added it the same folder with a domain name. Then Roon finished rescanning.
All my tracks are showing UNAVAILABLE!!!
I am wearing down my hard drives because of Roon. Now I have to AGAIN restore from backup, and pray that my playlists will be restored.
Thank you very much. I can’t tell you how much I don’t appreciate this.
Now that we are on the other side of version 1.8 and things have calmed down, perhaps the playlist synchronization feature can get a priority to be redesigned and fixed. I offered a couple of suggestions above in this thread, but the simple concept is that, Roon has a database of metadata of all library music, and when the music folders change, Roon should recognize and simply link the tracks in the playlist to the new locations of the tracks, without any hiccups. The burden should be on Roon, not on the users. I am tired of either restoring from backups or re-adding tracks manually to playlists.
The idea that, every time I reorganize my storage even slightly (as above, replacing IP address with Domain Name), my dozens of playlists get destroyed because Roon just doesn’t handle this properly, is ludicrous for such a high-end music system.
Also, I can’t be the only one chagrined by this Roon feature. I welcome your thoughts.
I showed the simple steps above to follow the RoonLabs instructions.
“I deleted the storage folder with the IP address. Then I re-added it the same folder with a domain name. Then Roon finished rescanning.”
It didn’t work.
The question is: did I make a mistake in following the instructions, or is Roon automatic playlist update/recovery broken/unreliable/full of bugs?
I don’t think there is a third option.
I even made sure the NAS name on the Windows 10 Roon server is properly recognized:
C:\Users\goran>ping TNAS-00618D
Pinging TNAS-00618D.local [192.168.1.64] with 32 bytes of data:
Reply from 192.168.1.64: bytes=32 time<1ms TTL=64
Reply from 192.168.1.64: bytes=32 time=1ms TTL=64
Reply from 192.168.1.64: bytes=32 time=1ms TTL=64
Reply from 192.168.1.64: bytes=32 time<1ms TTL=64
Ping statistics for 192.168.1.64:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
I’m sorry for the delay here, @G_Man — I’ve been out of the office.
Would you please use the directions found here and send us over a set of logs using a shared Dropbox link (or any other file sharing service)? I’ll take a look with the team. Thanks!