How Much Memory does Build 923 need to run Stably?

Mostly I use roon for background music on a Windows 11 work laptop with an i7 processor and 16GB of Ram. So it is not a dedicated roon core and I am working on the lap top at the same time. I have very little interest in chasing SQ and pay no attention to that as long it doesn’t sound obviously bad. Almost my entire local library on this laptop is Qobuz. This had started as a mobile workaround during Covid as we were staying away from home mostly but now it is my preferred way of using roon and up until now there have been no noticeable issues.

After build 923 I was finding roon very unstable with roon frequently crashing but running as few background programs as I dared seemed to help so I just put up with it. That was until I realized that overnight backups were failing as well as roon was crashing before the backups were complete. This was not obvious as in this scenario there is no “red triangle” warning that a back-up has failed. So I investigated in task manager.

I could see that probably since the 923 upgrade roon was trying to complete some task that needed peak memory of about 8.8 GB. This was triggering a backblaze transfer that was pushing memory usage, as monitored in task manager, to 100% at which point roon would crash. So the workaround has been to exit backblaze, stop listening to roon, and let roon do whatever it needed to do in background until roon peak memory usage had dropped below about 7.5 GB.

I have roon running now with backblaze back on whilst writing this post and I can see that roon memory usage is fluctuating between about 5.5 GB and 7.3 GB. Counter-intuitively, roon seems to use less memory when playing music and more when I am editing or adding files.

The situation at the moment is that I cannot play music, do edits and have backblaze on at the same time. I am not sure if I can play music and do Email, Word and Visio at the same time (which is what I really want to do) as it seems to be quite easy to push memory usage, as measured in task manager, into a critical area above about 97%.

. . . Well I have just answered my own question. Roon has just crashed whilst I was writing this post.

So my question is. I could add another 16GB ram to this lap top. Will roon use it? Will it stop the crashes? Or since build 923 can I just not use roon this way?

What size is you library?

On this laptop, almost entirely Qobuz, 185k tracks.

10,154 Qobuz albums
290 local albums

Sounds about right for memory usage. The database/library is loaded into memory.

Do you know if roon will use additional memory? Any comments I have ever seen from roon usually say that you can add more that 8GB to your core but roon will just use 8GB as if it is some kind of ceiling. In my case task manager is clearly saying that roon is going well above 8GB depending on task. From the logs it looks as if there is a lot of traffic to Qobuz.

I didn’t think this library was particularly large compared with some I have seen mentioned although roon often say that larger libraries are very rare in the user base.

My library is 7000 albums , 150k tracks and normally took up 3.x on my win 10 Core PC. I have 6gb RAM on that PC

I have moved it to a NUC so I can’t look for you 8.8 sounds excessive, as Ged says as far as I know Roon loads the library into memory . Maybe the library structure has changed ?

It may have something to do with this library being predominantly Qobuz rather than local. I only saw it hit 8.8 GB whilst waiting for roon to complete some task. Now it is more like 7.5GB and that seems to go down to 5.5GB if I am playing some music.

Roon / Backblaze are not interacting well. There is some task that roon is performing that creates files that Backblaze wants to backup and that can trigger 100% memory usage and roon will crash. It doesn’t make sense to me that roon hasn’t ringfenced the memory it needs so that other programs cannot use it.

Roon is constantly updating it’s DB files, so these files are rarely in a stable state to be backed up directy.
Thus if you not done so already I would recommend excluded the Roon DB folder from Backblaze.

What should be backed up are the Roon DB backup files, that are taken when the Roon app performs its own DB backup. However, I’d suggest that Backblaze does not attempt to sync those whilst the Roon DB backup is taking place.

As for RAM, the Roon app does not know how much RAM it needs, it simple request the OS to allocate more as and when required. If the OS cannot allocate any more then, it may start to page the memory to disk and then Roon’s performance takes a nosedive and can also result in it crashing.

I was running Roon on Windows PC with just 8GB RAM and whilst Roon ran (mostly ok) adding an extra 8GB made a huge difference to performance and stability.

The only sure fire way for you to find out what the effect would be is to add the RAM, but RAM is not that expensive … and the whole machine would run better with it (not just Roon).

Hope this helps.


Thanks Carl,

I seem to have reached some kind of memory limit. Excluding backblaze definitely helps. Crashes are less frequent. But there are still crashes. As you say, memory is cheap and it will help all program performance even if the problem with roon proves to be something else so I will start there.

wonder if this also could be the file folder of the orbit db issue

1 Like

Interesting. Trying that now. Only one orbit db in my orbit folder so taking a backup just in case :sweat_smile:

I can see that the combination of a backblaze exclusion and the orbit db fix has reduced memory usage reported in task manager to 78% whereas before it was hovering around 98% which was leading to frequent crashes. Roon memory usage seems high at 7.1 GB but it is stable. Before it was jumping around between 5.5GB and up to 8.8GB.

I’ll leave roon on for a while and report back the stability.

Well roon has been running without crashing for 4 hours or so now. I haven’t been able to do that since build 923 and probably since 918.

After deleting orbit_v3.db roon memory usage actually peaked at about 7.8GB whilst I assume it was re-building the db. But it never went above 8GB which with my library size seems to be some kind of danger zone.

Anyone know what orbit_v3.db does, and why deleting and rebuilding like this fixes the crashing issue?

The entire DB is loaded into memory? That doesn’t sound right.
My DB is 24GB, and Roon is only using between 5 and 6GB. I have 64GB installed.

I wonder what the logic is? My db is 19.1 GB but roon memory usage is pretty steady at about 7.1 GB.

The issue here is really the use of the word “database” as that can mean a lot of different things. There’s the library database which includes all of the metadata for your library content and that is the thing that is primarily memory-resident when Roon is running. That isn’t the complete content of Roon’s Database directory, though. There is quite a bit more data that Roon manages that is outside of the library db. The most sizable of which is a very large image cache which is accessed as needed depending on what you have displayed in the Roon UI.

Roon will attempt to use as much memory as it needs to and that’s going to depend on the size of the library and the Core’s workload. The 8GB figure was thrown out in the past as a way to help customers spec out their cores in that for the vast majority of libraries Roon wouldn’t need more than 8GB of RAM. Furthermore (and more importantly) adding more RAM likely wouldn’t make Roon any faster (or sound any better)

In other words, it was to help customers avoid wasting money on memory which likely wasn’t necessary for their library.

The exception to the above relates to large libraries and I would put anything over 100,000 tracks into that category. Large libraries will often push Roon well past that 8GB guideline and that appears to be what’s happening in your case.

Roon’s memory usage is highest when it’s doing a large number of database transactions and this is definitely the case in advance of a database backup or when you’re doing a large number of library edits. Playback uses next to nothing in comparison and since library churn typically isn’t happening during playback

Based upon your description, Roon’s memory usage doesn’t appear to be out of bounds. It does sound like Backblaze is going a little crazy at times so I would highly recommend excluding the Roon folder from Backblaze.

Yes backblaze definitely seems to have been a partial issue and I now exclude backup of the roon “Database” folder (by backblaze). But that wasn’t enough. What seems to have stabilized things is deleting the orbit db. As far as I can see roon then rebuilds it. What is the function of the orbit db?

This is related to some internal housekeeping functions that aren’t mission-critical. There was a bug introduced a few versions back which would cause Roon to get stuck while trying to process one of these functions and that was leaking resources. That’s been fixed in 923, but there have been a couple of cases where Roon was still having a hard time with it so deleting the directory and letting Roon re-create it is a solid fix.

Ok, strange. in my case I wasn’t really aware of any instability prior to 923. All looks good now. But I do seem to be skating close to some memory limit so from what you are saying if I add another 16GB roon will use it if it needs it?

Yes, and based on what you’ve described it will likely make your entire computer quite a bit better behaved.

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.