Roon lagging with larger library

Afraid it has nothing to do with your RAM and everything to do with Roon OS using native dotnet rather than mono.

2 Likes

I get that a lot on my phone remote. I have to kill the phone and app and restart and it tends to sort it then it’s quick until next time. I am using Rock Core with 8gb ram. About to add more ram to see if it changes anything, but somehow I doubt it will, I don’t have a huge library either.

The discussion becomes more and more exciting when experts and concerned persons exchange their views.

I already know the memory problem from Foobar2000. The only music library that can really manage very large collections (there is only a 32bit version). I still had to split it in two halves and Roon also needs two parts to acceptably use all shortcuts. Here only the disks T to X are started with Roon:

use limit at start

We see, much more is not possible with 16 GB RAM under Windows 10 Professional on this machine:

Roon optimizes in many places on all operating systems and after a happy start comes this display:

I observe that Roon always tries to keep itself at around 70%, because 96% as at startup is unhealthy. Unfortunately, this memory management means there is always a lot of reloading to do when even the GUI is still running on the same desktop. I therefore like to boot from a second machine. It still runs, as others observe, many hours round, but a daily reboot would also be my recommendation for large collections.

Roon offers so many ways to study music, and wants to remember too much of it at once, that must quite naturally come to memory limits.

In the phase where Roon is still being read in and the index is being written, the memory requirement increases.

With the change from 1.7 to 1.8 it increases further

…and the optimization of the metadata in version 1.8 will take many many days.

metadata optimize

…but it can still be used.

Memory management needs to be optimized, there is agreement on that. I would still answer the question whether more RAM helps with that with yes, because two other Acer with 8 and 12 GB RAM have failed at this task. 64 GB on the new XMG has not yet been tested.

However, we can see 16 GB is very very tight.

The memory issues don’t affect all system configurations either, and Roon still supports 1.4 million tracks on this very old 16 GB system when everything is optimized and the GUI is accessed via a secondary device.

From my tests so far with Roon 1.7 and Roon 1.8 (Windows, Linux, Mac, Android), Roon works up to the capacity limit and then clearly drops out like any other program or becomes very slow. That intensive use can also consume RAM, I consider normal.

Unfortunately, the world of sensible further development is changing because the basis is changing a lot. Will there still be a Windows 12? Is Windows 11 the best Roon solution on the desktop?

Try Linux too and you’ll be safe in the future.

Roon would like to see everyone on a Nucleus and still offer many alternatives. What developer building blocks will help in the future?

There are fundamental changes on the desktop. Microsoft is opening up to Linux and the Linux niche continues to cry to Windows. This is meant to be positive for Roon, because without Wine there would be no GUI (yet). Cry for it!

What lives on, what technology is dead for developers? Roon has to make strategic decisions on the technology side as well. RAAT is superior, but money is already being made with Fake-HiRes.

The Mac mini is not the problem as long it’s a 2012 or later with 16G of ram, and you are running Roon off an ssd, not your music files (that doesn’t help) if Roon itself with its index file that needs to be on an ssd. I run a library that’s over 2x your size with no issues.
I have run Roon on a $50k server with 256G of ram and $35k of nvme storage running Linux and Roon didn’t run any better than on my Mac mini. Roon doesn’t take advantage of a server with many processors, you need a computer with 1 high speed proc

Yeah, Strangely it worked fine for years but when it started to slow down it got really bad quite quickly. It wouldn’t surprise me at all if there was something else going on in there. Still, the NUC has been stable for a couple of months now.

Same thing happened to me, maybe not overnight, when my library was getting close to the 100,000 track size. I was running everything off a HDD and then switched running the OS X and Roon off of an ssd.

The best way to be faster again is always to restart. This must become routine until better solutions are on the market.

Your roon core must be installed on a separate SSD connected via USB to your nas. Otherwise it works too slow. (see: help, roon server on nas)

Best regards

As mentioned by Pim earlier in this thread, perhaps this can be addressed by having Roon Server / ROCK run on a dedicated machine. Not on a laptop which serves other purposes, not on the NAS, which runs a bunch of other apps AND holds the music files.
Like Pim, I run Roon ROCK on a dedicated NUC with a core i7, 16GB ram and 256 GB ssd. Nothing else runs on this NUC. It connects to the NAS, which holds over 500,000 tracks using ethernet and a GB switch.
No lag, instant response, instant search results, no dropouts etc.

Whatever Roon does or does not do, it seems to benefit from having its own dedicated hardware to run on, along with a direct wired connection to the music library as well as to the endpoint.
YMMV. I can only state what works for my large library, which I learned over time after multiple challenges and failures similar to those described here.

2 Likes

As @evand remarked earlier, there is a potentially significant difference between Roon OS (Nucleus or ROCK) that use Microsoft .NET, in contrast to Linux RoonServer, which uses Mono (the open-source clone of .NET).

1 Like

I understand and nothing in my post indicates I disagree with or dispute the potential difference. I am merely pointing out that Roon is quite capable of handling very large databases and libraries, as long as it is configured the way it wants/needs to be. Whether that requirement is reasonable, is a different story also.
A quick search will highlight all kinds of issues with Linux Roonserver, which (for reasons which greatly exceed my understanding) seems to be more sensitive, more picky or less stable.

Besides Mono vs .NET, there’s a lot of variability in Linux distributions, releases, and underlying hardware. RoonServer can be very demanding, especially with very large libraries, and subtle issues in memory management or hardware flakiness may only show up for particular distribution/release/hardware combinations. That’s one reason Roon Labs has released ROCK for DIY NUC server users: a controlled full software stack on a limited range of hardware. Those of us (including me) who want to roll our own Linux setups are very far in the tail of the distribution with respect to problem replicability.

There are a lot of ram-issue talk here, but no real troubleshooting tips other than running roon (core) itself on an ssd (in my opinion, this should be tested out, since index/database will benefit from this).

When roon lags, do some measurements other than memory.
What is the IOPS, latency, QD and troughput measurements on your NAS when roon hangs? (And on your roon server/client). Asustor is known to be a cheap option, but it shouldn’t be a big issue by default.

Except from when scanning from files, updating metadata etc, there should not be much load on the nas itself when switching tracks, even with a very large library. (This is where a database backed system like roon should shine).
What about cpu load on your client / roon server when it hangs?

Just yelling memory isn’t helpful if he actually has a decent amount of memory available.

And all this crap saying that having roon play from a nas is bad … seriously? What is your technical explanation for this? That doesn’t make sense. Running roon server as as VM on a cheap NAS might be a bad idea, but as I understand it, he doesn’t do that.

It might be easier to help if you give us some more numbers.

1 Like

Thanks guys. Some wonderful feedback here. Like I’ve said, I have a robust setup with the ST i9 and fiber internet wired connection. I will not be buying any new equipment. I already did this to try and get better performance and it backfired. Since I’m in the 1% of users I know this will not be addressed - other than a necessary process improvement that I hope they make. But I’m done. I’ve put several thousand $ into this system. If I have to reboot my ST i9 ever day cause of memory/cache issue so be it. Just done with putting any more money work into it. Hundreds of hours spent and I get that I’m not the normal Roon user. So I’ll just deal and hope they fix it. Eventually folks will have large libraries and this will crop up more.
Thanks again guys!

2 Likes

It would be worth discussing with Small Green Computer: what version of RoonServer they rely on, the Mono-based one or the .NET-based one. I don’t know whether Roon Labs restricts the .NET version to Nucleus and ROCK, or they also license it to their RoonReady partners. It could make a difference.

1 Like

@agillis perhaps Andrew can shed some light here.

I use a SonicOrbiter i5 with 2 tb internal ssd. Not nearly as large a library as yours, but I have 1000’s of hi Rez flac and dsd files, Tidal and Quboz highest quality plans and 1000’s of ripped CDs, and run lots of DSP to an ultra Rendu and a micro Rendu with zero lag. I bet if you used an internal ssd in your i9 that would speed up access time. Talk to SGC about an upgrade if possible.

With the amount of money you’ve already committed, upgrading the RAM on the ST seems like a cheap option to test. In addition to that I don’t see anywhere on the ST page where they list the specs for the internal SSD or the RAM. I’d be upgrading both! :slight_smile:

1 Like

Good that you bring this up, I got the same problem
I have six 6TB harddisks full of music, but I am still looking for a music software sollution that can handle this

The problem of many audio streaming software is that they use metadata import for analysing the albums, many many albums get lost because the program doesn’t know the album…

My advise to Roon and other audio streaming software companies is
create a simple music browser (with album cover art thumbnail) that treat the music like “what you see is what you get”
just like a file browser let you show all data on a certain harddisk
this way you don’t loose albums, and it much faster

Another advise for NAS users, read my review:
http://www.modelpromo.nl/JRiver%20DAS%20Server.htm
because Direct Attached Storage (DAS) is a much better and faster sollution for people with large music collections

Hi everyone, I wanted to share this post I made earlier for information about macOS and Linux with larger libraries: