really?
While waiting for the Roon team to look at my log files, I asked Claude.ai to analyze them. Here is what it said about the root cause of my performance issues:
Claude responded: Based on everything in the log, the root cause is the GC pressure accumulating during the overnight metadata run and never recovering during the day.
Based on everything in the log, the root cause is the GC pressure accumulating during the overnight metadata run and never recovering during the day.
Here’s the chain of events:
The overnight window starts processing your 78,000-track metadata backlog. This is a massive amount of work — Roon is fetching metadata from its servers, writing changes to the database, recomputing relationships, rebuilding the search index, and updating 28,000+ objects all at once. All of that allocation and churn fills up the .NET managed heap. By the time the window closes at 6am, GC is already sitting at around 13% of runtime — that’s not a clean baseline, that’s a heap that’s already under pressure.
Then during the day, Roon never gets a quiet moment to let the GC fully collect and compact. Every time you browse — querying 104,820 tracks, loading album details, fetching performer pages, rendering the Discovery screen — Roon allocates more objects. With the heap already stressed from overnight, the GC has to work harder and harder to keep up, which is why you see it climbing steadily from 13% to 27% over the course of the day without ever coming back down.
The 27% figure is the real problem. At that level, Roon is spending more than one second out of every four frozen in garbage collection rather than responding to your input. Combined with GC pause durations creeping up to 200ms+, that’s where you feel it — sluggish navigation, slow album art loading, UI that hesitates before responding.
The underlying reason this is so bad is the metadata backlog itself. Your queue had 77,000+ tracks waiting for a refresh that was already 3+ days overdue when the log started. That’s not a normal steady-state — something caused Roon to fall behind (possibly a server outage, a Roon restart at the wrong time, or the server being off during the scheduled window). A normal overnight run on a library your size would process a much smaller incremental batch, leave the heap in better shape, and not carry this much pressure into the next day.
What to expect going forward: once the metadata queue drains down toward zero — which will take several consecutive overnight runs at ~60 tracks per batch — the overnight work will be much lighter, the heap will be in better shape at 6am, and the daytime GC pressure should drop significantly. The 861 unidentified albums also contribute a small recurring cost each night, so working through those will help too.
If the GC pressure persists even after the queue drains, the next thing to look at is how much RAM your Roon server machine has. A library of 104,820 tracks is at the larger end of what Roon handles comfortably, and the log shows it using ~4.6GB of physical RAM with another ~70GB of virtual address space mapped. If the machine doesn’t have headroom well above that, the OS will be under pressure too.
Yes. This makes a great deal of sense.
Probably by far not the worst explanation
The overnight thing is interesting, because the first morning after the update, my fanless NUC 7i5 wouldn’t connect to Qobuz or any end points, and felt like I could fry an egg on it. I tried a few things and got frustrated (actually started looking for Roon alternatives because I’m tired of this I.T. b.s. and just wanted to listen to some music). Then I remembered to go restart the server via browser (for some reason a physical shutdown didn’t do the trick) and all was restored. It’s been a bit warmer than usual but working as it should. Really tiresome, Roon…
Today I have turned off the scheduled background audio analysis just to see if it makes any difference tomorrow or maybe the day after.
This is how I’ve been feeling lately.
So I gave Claude.ai today’s log file and asked to further evaluate since yesterday’s log (I have not rebooted the Nucleus in two days). Interesting info about my MacBook as an endpoint. I’m going to remove it.
Claude.ai said:
This new log strongly confirms the earlier findings and adds some important new details. Here’s the full picture:
GC Pressure: Now a Permanent Fixture
This is the most important new finding. In yesterday’s log, GC pressure started at 13% and climbed to 27% over the course of the day. In today’s log, it starts at 30.6% and barely moves all day — ending at 30.06% by 11:30am. The GC pressure isn’t recovering between sessions anymore. Roon is carrying a heavier and heavier memory burden across restarts.
The pauses are also worse — 286–293ms by end of log, up from ~200ms yesterday. That’s nearly a third of a second of freeze on every major GC cycle, happening continuously.
The Metadata Queue Is Not Draining
This is the smoking gun for why the GC problem is compounding day over day. Yesterday’s log ended with the queue at 77,602 tracks. Today’s log opens at 77,821 — it actually grewslightly overnight rather than shrinking.
At the rate observed (roughly 50–66 tracks per batch, one batch per ~60–90 seconds, over a ~3.5 hour window), the overnight run is processing somewhere around 8,000–9,000 tracks per night. But new tracks keep getting added back to the queue as their metadata timestamps expire. With 77,000+ tracks overdue, the queue is essentially a treadmill — Roon processes some tracks, their timestamps reset, but so many others are due that the net queue size barely changes. It may take weeks of consecutive overnight runs to fully drain at this rate, assuming nothing interrupts the process.
The Overnight Endmutations Are Getting Worse
This is new and alarming. Yesterday the worst endmutation was ~95 seconds. Today:
-
endmutation in 122,758ms— over 2 minutes -
endmutation in 99,274ms— just under 2 minutes
Both happened right at the tail end of the overnight window (5:58am and 6:00am local). This suggests the database is getting progressively more stressed with each overnight run rather than getting relief. The heap is larger going into each window, which makes the commits heavier coming out of it.
The MacBook Air Problem Is Getting Much Worse
Yesterday there were a handful of RAAT failure cycles. Today there were 26 “giving up” events spread across the entire morning from 6:15am through 11:24am — roughly one failed reconnection cycle every 10–15 minutes. Each cycle burns about 90 seconds of retry attempts before giving up.
This isn’t just noise. Each failure triggers a zone destroy/recreate sequence in the transport layer, which causes library mutations (you can see the endmutation in 731ms and endmutation in 1657ms events tied directly to Mac reconnection activity). So the flapping Mac is causing daytime database writes that wouldn’t otherwise happen, adding to GC pressure during hours when the system should be idle.
The pattern — connects briefly, immediately drops, retries for 90 seconds, gives up, tries again 10 minutes later — strongly suggests the Mac is going to sleep but not properly suspending Roon before it does so.
Summary: What’s Changed
| Issue | Yesterday | Today |
|---|---|---|
| GC at start of day | 13% | 30.6% |
| GC at end of log | 27% | 30.1% |
| Worst GC pause | ~200ms | 293ms |
| Metadata queue | 77,602 | 77,821 (grew) |
| Worst endmutation | 95 sec | 123 sec |
| MacBook RAAT failures | ~5 cycles | 26 cycles |
The situation is trending in the wrong direction. The most actionable thing you can do right now is remove the MacBook Air as a Roon endpoint (or fix its sleep behavior), since that’s causing active daytime mutations and RAAT churn that’s entirely avoidable. The metadata queue problem will resolve itself over time but only if the overnight window runs uninterrupted every night.
I think I’d also turn off the scheduled background work for now and try letting it do its work 24/7 until it settles down (if it ever does), because currently it looks as if the limitation to a few hours makes matters worse.
@suedkiez What will be your setting. Throttled or one of the fast solution ?
I’ve implemented a daily reboot into my routine.
Used to be my computer now it’s Roon. 
That’s probably not the best idea. It doesn’t allow the scanning work to complete properly and will never get to a point where it works fast. If you let it go, eventually things will catch up and it will start working faster.
Quick question - why would unidentified albums matter if your maintenance is restricted to middle of night? (A question not a statement. 
)
Can Roon match the metadata cycle timestamps to the speed of the refresh?
Unidentified albums are continually analysed, which loads the server. The more there are, the greater the impact.
I would have thought that is included in the background work time restriction window
Yeah, I’m not great at multitasking, and should have added what you said. 
Public service reminder for those feeling inspired to dip their toes into the AI waters: your logs contain personally identifiable information so be thoughtful about how you share it (or don’t).
Examples of PII in your log files:
-
Roon authentication token
-
Roon user id
-
Email address associated with your Roon account
-
Information about your Roon host computer
-
Your external IP address and internal device IPs
-
Your approximate location based on geolocation data from IP address
And just a reminder that chat bots confidently hallucinate. If you don’t know about a specific topic, AI can and will boldly (smugly?) present incorrect information without you ever noticing it. It’s a hassle, but please verify what AI regurgitates.
This is an interesting correlation, but audio device disconnects do not cause database churn. It’s the other way around - lengthy GC pauses on the Roon server can and will cause network disconnects. See the following analysis for my take on the situation.
Claude’s advice below is flawed and if followed, the actions will be ineffective or meaningless when it comes to database (music metadata) updates.
The metadata queue will resolve itself over many hours or days 
How long database mutations can take
Size of flushing memory data tables to disk in megabytes
How long it takes to write the data to disk
Overall picture of Roon server running scheduled maintenance job maintaining the music library
These activities were not caused by audio device disconnects from Roon server.
Intresting discussion! I have Roon on QNAP since years (and now on container).
I automated to send my QNAP to sleep state every night 1am to 8am + 2 reboot per week and never ever had any issue with Roon and metadata. Not super fast but not very slow either…
“Only” 15k albums here
G
Yep, happened again this morning. And I was trying to play a friend something, but instead tearing my hair out. Looking for options. And I’m a lifer. I like what ROON does, for the most part, but it has become a p.o.s., p.i.t.a. piece of software, with ugly design and poor UI since 1.8 on top of all the server issues. A shame, as I’m invested in hardware to play it. Almost ready to go back to playing cd’s and albums, drop Qobuz, and add on to the Spotify account I already pay for my teens. My blood pressure can’t take this nonsense. Just work already, PLEASE!