I can’t help with an answer to why your music folder looks like that. But if you have only used Roon 1.3 and never used Roon 1.0, 1.1 or 1.2, then I don’t think Roon is the culprit. From v1.3, I don’t think Roon has the capability to edit your files, move or rename them. So it’s hard to see how Roon could have done it.
Since all those folders and files were created about 2am today, perhaps check and see if you had any other processess scheduled for 2am - backups, disk maintenance, anything else?
David please check the folder names via the FileManager in Symbology’s DSM desktop. If my hunch is right you will find the folder names all in tact via FileManager. If my hunch is correct you’ll also find that the folder names have used a special character not permitted SMB. Here is a link to a thread that I worked out a similar issue.
This is a relatively common issue when mounting shared from certain NAS’s on Macs. It is impacting the Mac’s ability to understand the filenames. So it’s displaying “mangled names”–placeholders–instead.
This is not a symptom associated with any kind of data loss. The files haven’t been renamed or moved around by anyone, they are just displaying incorrectly.
I’ve never run into this situation with a NAS personally, so I don’t know exactly what the fix is going to be. Hopefully someone else here has a good answer. Synology’s support team may also be able to help.
This stackexchange thread might be a decent starting point:
The actual behavior is called “mangled names”–that might help you with search terms. I’d start with “synology mac mangled names”.
But I wanted to reassure you:
Roon did not move your files around–even pre-1.3 we did not create directory structures that looked like this, and 1.3+ builds no longer contain code that moves media files around at all.
Your data is almost certainly just fine. Once you resolve the configuration issue things should be back to how they’re supposed to be.
@brian Thanks so much for the reply. I think, and hope, that you’re right about my data being intact. However, I don’t think this is just an SMB naming issue. I’ve been connecting to this NAS via SMB for years with no problem. I tried connecting to the NAS via the Synology DSM FileManager. It kept hanging with a non responsive script, but I eventually got it to load. What I find is 27K files related to Roon backup.
It would appear that rather than create a folder called RoonBackups to contain all of the backup files (which then results in a fairly deep directory tree containing tens of thousands of files) Roon created a bunch of folders with names that contained the full path name in the folder title! Yikes!
Why this is happening is something that needs to be solved, but in the mean time I’m 99.9999% confident that your music folders are not impacted. If you click on the >| at the bottom of that file browser window you should see the tail end of your artist folders.
These folder names that got created are extremely long, which isn’t a problem for the Synology or Sonic Transporter (Linux), but they’re too long for some SMB implementations so the path names are getting mangled in the Mac’s finder view. On the Mac things that start with a non-alphabetical character are shown first so that’s why you’re seeing all of the gibberish first in the display.
So how to clean up? Well, if it were me I would just go into Roon’s backup settings and clean (delete) all of the prior backups, which should result in all of those files being removed… but that’s just me and I have multiple backups of my library so even if I blow something up recovery of the library is a click away.
I think it’s wise to get @support pulled back in here just to make sure that we don’t make the problem worse.
The backup is being run on your Sonic Transporter which is writing files to the Synology. There could be an issue with the SMB implementation that the Sonic Transporter uses which could be leading to this rather ugly bug. I’m running a couple of cores on Linux accessing a Synology share for backup and have never had a problem like this pop up so I’m more inclined to say that this is an issue with the ST’s implementation of SMB rather than how Roon is doing its backups.
My concern here is that the Sonic Transporter’s writing of your backups created the issue in the first place and I wouldn’t want to see an attempted mass cleanup result in an accidental destruction of your library. That shouldn’t happen, but neither should the problem that you’re trying to correct!