My experiences with Rock and a 500k+ tracks library

So, @brian: if I’m migrating a library to a completely different server which has exactly the same music files, except that the paths to them might be completely rearranged (either because of a regrouping to split things across available physical devices on a new Linux server or the above PLUS moving to a Windows environment with freakin’ drive letters)…

Is this How do I move my collection to a new folder, hard drive or NAS, Will I lose my edits? the complete how-to (perhaps along with the companion KB entry “How do I move my Roon library to a new computer?”), or are there any other best practices one should be aware of?

Basically, our existing RoonServer setup is, um, suboptimal in a number of ways, one of which is that the tracks are being read from two distinct mounted volume shares from NASes, and (because of history having to do with how music is stored on those shares, with some areas holding tracks Roon should index and other areas holding tracks which should not go into the Roon library) there are cough seventeen distinct watched folders set up in Roon, pointing at subtrees within those two mounted shares.

My plan is to have the new Roon server read tracks from three internal spinning disks, each one containing only tracks Roon should read (the weird earlier go/no-go rules now incorporated in the script which will keep the internal disks updated from the NAS masters rather than in Roon’s watched folders lists), and have just three watched folders: one for the top of the tree of tracks on each physical local track-storage disk. Any obvious problem with that scheme?

…and if I follow the advice above (disable, apparently no need to actually delete, all the watched directories in the current RoonServer, then shut down and grab a database backup, then migrate that database to the new hardware) – Roon should actually recognize albums in all those different places, and retain my laborious edits over the last couple of years like gathering multi-disk sets together into one album, finding an existing release to tie unrecognized albums together, per-album tag and image source overrides, track and album tagging?

Also… to try to minimize downtime, I’ve been thinking of getting the new server going and tested with a 60-day trial license, then rolling the production database in. Are there any gotchas there?

@danny and @brian, you guys rock. it’s a pleasure to work with your stuff.

1 Like

Your scheme sounds fine to me.

That KB Page was written carefully. @danny, @mike, and I spent a couple of hours figuring out exactly what the best order for the steps was and how to communicate it. It’s good. You should follow it :slight_smile:

Roon stores library content segmented by account ID, so if you switch logins, you don’t end up loading the same db. Use the trial account to test your migration procedure, make sure you’re satisfied + there are no issues, then repeat it for real on the real account.

Don’t hesitate to get in touch during the procedure if anything feels wrong.

1 Like

Cool. Fancy overfast 8th-gen i7 machine configured; cough Windows 10 stuck on there; codec support added back because I didn’t realize Win 10 Pro N left out stuff RoonServer would want; RoonServer up and running with a trial license while I stress test the machine some with a full import of the tracks which will have to be re-introduced later…

I’m trying to figure out how to specify the location for the Roon database on Win10. I have a blazing NVMe Samsung 970 Pro on the motherboard as a completely separate disk from the boot disk, and that’s where the Roon database should live… I’m not finding instructions for how to specify that separate database location to a Win10 RoonServer.

I see that there’s some stuff under


so I’m wondering if the database lives under there, and if it could be pointed somewhere else with… what, a symlink, or that Windows-y join thing?

There are also those foo.exe.config files, so I wonder if modifying those would be part of controlling where the database lives…

…and when I roll in my backup of the production Roon database from the current (Linux) server, will that funny number be different?

Basically, how do I do this properly?


We don’t support custom database folder locations on Windows/Mac. Danny or I did a long write-up on why once, but I’m having trouble finding it. I don’t think anything bad will happen if you figure something out in Windows. If you do, redirect at the RoonServer folder level.

The funny number will be different, and so will some of the DB contents–which will reference the different account/profile ids. That’s why you should import using the “real” account once you’re past the test-run phase.

1 Like

You are thinking of “junction”. That’s the magic link type you need to cross physical disc boundaries. You’d use the mklink command to make a junction from User\AppData\Local\RoonServer to a RoonServer folder you create wherever you want on the Samsung NVMe drive. Using a junction, Roon won’t even know its walked through a reparse point…

Make sure to shut Roon down entirely, then MOVE the RoonServer directory from User\AppData\Local to wherever you want it, then make the junction in place of the original directory to point at the relocated directory.

1 Like

Thanks! Some hours after I posted the above, while walking down the street, I thought: “I think I pulled out the wrong J-word when I wrote that post.”

1 Like

Thanks for indulging me! I’ll give that approach a try.

One sub-thing I wanted to attempt to do – since I’m going through the bother of trying to make this particular server damn close to optimal for RoonServer – was to see if I could get Roon’s logs (since I’ve noticed Roon can occasionally be pretty chatty) going to a different device from the Core database itself. Probably not enough of a factor to be worth thinking about, really, but it’d be interesting to know if the logs get written under the RoonServer folder or in some Windows system place.

If I can move this RoonServer folder without causing any kind of allergy fit from RoonServer, I’ll be happy to stop there.

Also – if it would be in any way less troublesome or fragile for me to just relocate the entire user home directory for the user which owns and has installed RoonServer to the speedy database SSD volume, I’d be happy to go with that approach instead.

Logs are written in RoonServer/Logs.

Putting them on a separate volume is a pretty small optimization, though. I wouldn’t worry about it, personally.

Might be. We are going to put our stuff in whatever Windows thinks of as %LocalAppData% (You can do Start->Run and type that in to locate the folder). Moving the user’s folder is definitely a cleaner way…

At least on Linux, RoonServer rotates log files when they hit 8MB in size, and keeps a maximum of twenty. So you won’t really gain much here. You’re looking at a max of 160MB for the logs…


I just became a lifetime member or Roon a couple of months ago. I did so after a very brief trial run of Roon on a Synology DS1513+ which has an Atom duel core processor with 2GB RAM. It is way underspeced for what you recommend…and it worked just fine. Good enough for me to give no thought to purchasing a lifetime Roon account. I followed some advice and upgraded to 4GB RAM and moved the core to a SSD. I keep the music files on the spinning disks. I do occasionally have some slow performance but it is never horrible. I just have to wait a few seconds. This issue could be many things. There are a lot of things happening with Roon. It could be a slowness issue with Tidal or the Internet outside my home. It could be issues with the wifi inside my home. It could be the NAS too. But overall it is very good.

I don’t understand this aversion to using the NAS. It seems like forgoing the good in search of perfection. Frankly if I needed to buy more hardware to make Roon work I would have not used it. The fact I can use my existing hardware for a very minimal investment got me on board, and I’m very happy. Roon sounds great. The benefits far outweigh any issue I may have using an old outdated NAS. Thank you for a great product.


I do want to point out that you are responding to a post about using a NAS to hold the music being played by RoonServer which is running on a different PC; not, about using the NAS as a RoonServer.

In your case, your music IS local to the RoonServer; so you are not going to run into those issues. Now, if you pointed the RoonServer running on NAS1 to music stored on NAS2, then you would run into the same issues.

Thank you for this information. What you are saying was not clear to me. I was responding to Brian’s post, “I hate NAS’s for music storage. I know that some people like them/need them, and we do support them, but I wouldn’t use one for Roon (or any software trying to manage 50-100k+ music files) for myself, regardless of library size.”

To me that comment was about the NAS in general, and not about a NAS connected to a server. But perhaps I am not I understanding this thread.

My complaints in that post focused on problems related to accessing NAS’s over the network from a core running elsewhere. Those problems do not apply when the Core has local access to the files.

You might find this interesting:

Well… getting pedantic about the acronym NAS – but it’s useful pedantry in this case – NAS stands for network attached storage.

Since the filesystems in a NAS box aren’t network-attached to that box, they’re local – the NAS isn’t acting as a NAS from the perspective of processes running inside that box. The storage is only network-attached on external hosts the NAS box serves.

I could imagine there being issues with running RoonServer on a NAS box related to the CPUs on NAS boxes often being lower-performance than the CPUs on current generations of general purpose computer, but I understood Brian’s earlier remarks to be about issues with storage mounted via the network versus local storage. But of course, IANAB (I Am Not A @brian).

Hi Brian,

Thanks for providing this information on Rock.

I have a large music library and was previous running my core on a Synology DS3617xs with some success. To reduce power and reduce some of the burden off my NAS with the Roon core struggling, I thought I’d try running it on a Rock system.

So I built up one using a Intel NUC i7 (Intel BOXNUC8I7BEH3), 32GB RAM, 4TB SSD, 256GB M.2. The larger SSD drive hosting my Master music and all the MP3’s stored on my NAS.

With my collection now over 1 million tracks, the Rock core is running out of steam and becoming sluggish. It’s purely the shear quantity of music/database entries.

My question is, have a reached a maximum limit to Roon or is it just this hardware configuration? If it’s hardware than can you point me to an ideal core hardware configuration that will not expire with a growing collection? If the limitation is Rock software, are their any improvements forcast?



Probably should tag @brian for you here. Maybe going with a non NUC solution could be the best option but if it can’t run ROCK maybe a Linux build or you might need to go with windows.

There is now an i9 version of the SonicTransporter. But with a library that big running off of NAS’s, just juicing up the CPU may get you nowhere.

Roon 1.7 on the latest RoonOS will outperform any other platform out there, including other Linux systems, other manufacturer’s Roon Core devices, and MacOS/Windows.

We have ~10 libraries out there that are this size. 1million tracks is REALLY big, but should be doable with the right gear.

You will want a faster system than the NUC.

Which would be what?

That seems like a pretty hefty system.