My experiences with Rock and a 500k+ tracks library

Maximum single-threaded speed in the core is the main determinant in user experience snappiness.

Multiple cores helps with running more zones in parallel with more DSP and will complete stuff like audio analysis faster. I wouldn’t go beneath 4 cores/8 threads for this use case. You could do more, but added value will diminish depending on how much you value those aspects.

I understand the preference for Linux (and wouldn’t want to run Windows if I could avoid it), but in your shoes I’d do an A-B test and come to a personal understanding of what the differences are before making up my mind. It costs nothing but a few hours to install Windows without activating and learn the situation.

Here’s my feeling: Despite ongoing improvements to mono and more and more code from Microsoft.NET being merged in, Microsoft’s garbage collector is still better at handling the massive in-memory object count that comes with a library of that size. For most libraries the gap is negligible–there’s just some design choices in that GC that start to become more painful around 4-5mm objects on the heap, and really large music libraries can push things that high.

I don’t think Microsoft’s GC is ever going to make it into Mono. I think instead they’re going to keep making .NET Core better until Mono is displaced. At some point they will reach a point where we can switch to .NET Core. I have a hard time imagining Microsoft doing that and us being able to start that effort until a least a year from now, but it could be more depending on whether .NET Core 3.0 is actually viable or we need to wait another iteration.

In other words: if you didn’t have a strong preference for Linux, Windows/Microsoft.NET is the safer recommendation at this unusual scale. Since you do, it may be worth the extra few hours to try it both ways and see, just in case the Linux performance on a fast machine is good enough and you can avoid the Windows headache.

As for other hardware choices:

  • High-End Desktop vs Server CPU: High-End Desktop. Especially now that there are Threadrippers and i9’s, there’s no reason to buy a Server CPU for something like this unless you need Server motherboard features like redundant power, remote admin, etc. 4 Cores/8 threads is probably fine. You could go up to 6-8 cores especially if you see yourself running more zones/dsp.

  • Intel vs AMD: We test, develop, and ship hardware based on Intel, so there’s some passive bias. That said, AMD might get you more performance for the same $. I have a very, very fast AMD machine here (built for batch processing/machine learning) that runs Roon very well. I wouldn’t worry about it too much.

  • NVMe SSD is a good idea. Larger sizes tend to be faster, too up to a point. Samsung 960 Pro is very good.

  • Definitely store the music on local (USB3 or SATA) drives and stop watching the NAS. This will help more than you think.

  • For 640k tracks I’d consider going to 32GB RAM. Even if Roon doesn’t use it all, you’ll benefit from extra filesystem caching + more breathing room.

  • If you wanted to try ROCK, NUC7i7DHNE is the best NUC right now. You can hang USB drives off of it and it will support the storage. It can take an NVMe SSD and 32GB of RAM. So it could work.

  • If you want to build an even bigger machine, run Ubuntu or Windows. Getting a shell on ROCK is more difficult if you want to do sysadmin stuff like setting up cronjobs, rsync, etc. So that may push you in other directions.

That covered what I can think about right now. Any more questions/clarifications, let me know. I’d like this build to be a success for you.


Thank you very much! That was a thorough answer, delivered admirably quickly.

If I’m bothering to do this upgrade, I expect I’ll go ahead and build it into a box which can fit the spinning disks internally so they can be connected by SATA rather than USB3. I associate USB interfaces with high overhead even if USB3 offers high bandwidth; although maybe that’s a prejudice left over from an earlier age.

Oh, what was the end of the thought which began “Samsung has a good…”?

Also, if I’m bothering to do this upgrade… I might as well actually hear your advice to try Windows. I have Win10 Pro N media I can bust out, and I’ve already been through the exercise of learning where to turn off some of the most egregious unnecessary cruft. If I’m to survive such an exercise without cursing so much that I burn my desk to ashes, I’ll have to find a good Unix-flavored tool set, especially for SSH and file copying. I hear this rumor that Microsoft is actually supporting some Linux applications with a compatibility library of their own… if that actually works, and I don’t have to install Cygwin, maybe this could be less terrible than usual.

And I’ll have to keep my ear to the ground for a particular combination of Intel-CPU motherboard and NVMe SSD models which are known to work well together, since I think I’ve heard about some incompatibility nightmares in the field.

I would think it was going to proceed along the lines of … track record or history of stable performance and reliability. :smiley:

I was going to call out the 960 Pro as a quality NVMe SSD (edited above to fix)

I’ve never run into a compatibility problem with an NVMe SSD, and have installed several at this point on both Intel + AMD–they’re simple machines. Just PCIe on an alternate connector.

I don’t think USB3 is a real negative for media storage other than the additional boxes/cables. Maybe some background stuff you barely pay attention to will go <5% faster? That’s about all I’d ever expect. USB3 is fast enough that the drive should be the bottleneck. Of course if you’re using a larger case/motherboard and not a NUC, go SATA.

I haven’t played with Microsoft’s Linux support much, but it looks like it might work now that they’ve solved the filesystem bridging stuff. Another option would be to use Docker for Windows + expose the media drive to a docker container as a volume. Cygwin works…it is just slow and kind of annoying.

1 Like

Hi Brian,
that is an intriguing comment. My music is split between USB drives and a NAS. Is this an issue only for those with very large libraries or does it affect everyone regardless of library size?

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.

They don’t support real-time watching for file changes very well, scanning them over the network takes 10-20x (or more) as long as a local disk. Because they don’t support filesystem watching very well, you pretty much have to scan the whole folder tree periodically to avoid missing changes.

Also, because networking is in the mix, there’s a whole litany of extra broken states they can get into, ways they can confuse the OS or the software, and weird behaviors that they can exhibit. Performance varies greatly from product to product, and sometimes the performance can be so bad that it causes major behavioral problems.

On some networks, or with some NAS’s, the connection to the filesystem bounces up and down several times a day, or more often, triggering Roon to re-scan the folder tree too many times.

With a large library, sometimes you can end up with Roon spending a decent fraction of the time scanning over the NAS for changes because the connection is bouncing up and down or just because it takes so long to walk the folder tree that the periodic scan every few hours (frequency is configurable) turns into Roon doing work a serious fraction of the time just to keep tabs on your files.

I keep my music on a USB drive hanging off of a ROCK-based NUC. It’s something I never have to worry about, and I like it that way.

I do use a NAS for a backup copy/archive of the music, and for some other stuff like video streaming where the much lower file count makes most of the disadvantages disappear.


Thanks Brian, the team Roon hatred of all things NAS is fairly well known. I am surprised that you support Roon core running on a NAS under the circumstances but I suppose that removes some of the network related issues with scanning. Now to search for that thread which states how big a spinning disc I can get in the NUC…sure it used to be 2TB but might be 4TB by now?


With a 500K track library you are almost certainly into the multiple 12TB spinning drive scenario… I an out space at 12TB drive for a measly 200K library. This has meant back to NAS as my windows based i7-7700 fanless chassis will only support 1 x 3.5" drive … and it was a noisy drive too…so I am looking at another option perhaps raid 0 based external USB3 or splitting my music over 2 volumes. My NAS is 6 x 6TB raid 5 or another 2 x 12TB JBOD that back up each other

Hi Tony

It depends on the physical size of the drive, not the capacity.
The drive can only be not higher than 7 mm, so most (if not all) drives with more than 2 TB are too high to fit in the NUC :frowning_face:

Thanks but 70mm? Are you sure, sounds massive, the NUC is about that tall itself! thought the limits was more like 9mm or so? I have the 7i7BNH which is quite slim.

Sorry, you are right. I meant 7mm and I changed it in the posting above :flushed:

No probs, the spec says 9.5mm, which means a laptop type drive will be required (7mm), as all the others are usually 15mm.
Apologies for going OT!

Yeah, none of the stuff I was complaining about really applies if you are runnnig Roon on the NAS itself—since then there is no networked filesystem involved.

The main caveat with running roon on a NAS is that many of them have underpowered CPUs, and it is easy to end up with Roon’s database on a spinning disk, which isn’t great…but both of those are surmountable by making good hardware/configuration choices.

Hey Brian. Forgive this silly question.

But does this ~500k number only apply to 500k locally stored files or does the same apply to a Roon library that had 500k Tidal tracks?

Or does it apply equally to both?

Assume that all background audio analysis has been fully completed for a 500k locally stored library.

Equally to both. Database works just as hard in both cases to manage the content…


I run a large library on 4x6TB in a USB3.0 box. Raid 0.

Backed up to several NAS and other USB drives.

Works very well with snappy responses with all tasks.

I have 6x6tb in my nas as shr and about to add another 2 x 6tb drives one for data and another as spare

My other nas has 2 x 12tb jbod as backups. I have maybe 10 other 6tb drives around for other backups…I’m well sorted :slight_smile:

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