Roon lagging with larger library

I commend your optimism. My outlook at this time is more pessimistic, though.

Different file systems rely on memory buffers in different ways. Problems of this type are typically caused by relatively unusual, hard to debug interactions between apps, operating systems, memory, network, storage systems. I don’t know what the problem is in this particular case, but in other cases I’ve seen quadratically inefficient performance because of interactions between memory management and caching of recently used stored data.

Good point! It could be many things, but that fact that a reboot fixes it for a while and then as you play more songs the lagging comes back. That we can establish. Something within the Roon cache/memory fills up. I have no clue how/why this happens. And support doesn’t seem to either. I do understand it’s not an easy fix. They can look at my logs all day. But I’ve done this multiple times and eventually the thread just dies. Cause people with large libraries like mine are a small bunch. Just the way it is but I do hope some wiz figures it out.

how much RAM is in your ST i9?

Now there’s a phrase you don’t see every day! What does it mean? Google not much help.

1 Like

It means in this case a memory management issue where the time taken to allocate a new chunk of memory is proportional to the amount of memory already allocated, so overall cost to allocate N bytes of memory ends up proportional to N squared. This can happen for subtle reasons such as memory fragmentation, where rapid allocation and reallocation of memory chunks for different purposes causes the overall memory to be broken up into in-use and free chunks, and finding enough contiguous memory for a new chunk may require examining the whole memory.

As I said earlier, I don’t know if this is what’s happening here, but having written quite a few memory allocators in my time, I’m familiar with the problem, even though I’ve been away from that kind of systems work for a long time.

1 Like

8GB of RAM (DDR4)

8GB is almost certainly too little for your size of library, as is pointed out on the help page posted by Dylan earlier in this thread. Personally, I would double it at least.

4 Likes

But is it? This can be easily measured (unless you run a ROCK). There has been no root cause diagnosis of this issue, that is the problem. As it potentially only impacts the 0.01%, I fear we won’t get one.

1 Like

I can confirm this statement from my own trials with 4 computers. 8 GB goes down at 300,000 to 400,000 music tracks. 12 GB is enough and with 16 GB reserves larger databases should still be able to be built up.

The processor is unfortunately not the critical point. My 10 year old Acer 8943G with 16 GB still outperforms two younger Acer i5 8/12 GB and even my XMG Ryzen 4800 with 64 GB and Nvdia 2060 graphics card causes more problems because of the hybrid graphics solution. There I do not even get a TV monitor connected as a 2nd screen because drivers are missing for Linux. Optimus could solve some of the problems.

New is not always better, but not yet matured, tested and free of problems. However, this also applies to software :wink:

The STi9 is built for large libraries - over 100K songs and also for upsampling in HQ Player and Roon DSP. This thing should be able to run fine with my large library. That’s why I purchased it a year ago.

I’m betting you need to be at least 16gb

1 Like

Just a s reference point… this is my Roon Core (Ubuntu server 20.04), with an Intel Core i5-8600K@3,6GHz and 16GB DDR4 RAM@2133MT/s, connected via Ethernet to my router. I am at 198.000 tracks at the moment. The OS is up for 15 days, Roon server was restarted yesterday afternoon, less than 24 hours ago. It is nearing 5 GB RAM use, and I’ll soon have to restart again, when the UI lags become noticeable.

This is a headless setup, no OS GUI, no other apps running apart from Cockpit for remote administration.

Screenshots were taken during playback of Tidal FLAC 16/44 to one RoPieee-connected endpoint. No upsampling, no DSP processing.

I don’t experience Tidal dropouts, all works fine… until physical memory usage goes upward of 5 GB… then UI interaction on the Remote (iMac) becomes slower and slower… This is resolved by a simple restart of the Roon server process. Then, after loading everything into memory, RAM usage can be anything from 3,3 to 3,6 GB.

Screen Shot 2021-09-03 at 11.35.42 AM

1 Like

An hour later… looking up two albums, saving one into the database. Playing back two albums…

Same boat here. It’s a memory usage issue, nothing at all to do with whether files are on a network or directly attached storage.

Roon has memory management issues, it’s been that way for years. Like most things that only affect a minority of Roon’s users, it remains unaddressed and is unlikely to get any real attention.

3 Likes

Case in point…:

2 Likes

How long since the last restart of Roon server? I can’t remember having ever reached such high memory usage… long before I restart to be able to enjoy my music.

Six hours later…

1 Like

As a possible confirmation that more memory might solve the issue:
My system: ROCK on a NUC (Core i7 10th gen, 16GB DDR, 256 GB SSD, fanless), with all music files (28,300 albums, 510,000 tracks) on a Synology NAS also with 16 GB RAM and SSD cache (2x400GB SSD in Raid), 92 TB of conventional hard drives ). Everything is wired ethernet to the same switch.

Searching tracks or switching tracks is virtually instantaneous.