Long delays between tracks on GentooPlayer NUC, worsens over days (ref#QDL513)

Support
1

What app are you having the slowness issue with?

· Roon

What kind of performance/speed issue are you experiencing?

· Tracks take a long time to play

Please try to reboot your Roon Server

· No, the issue is still the same even immediately after a reboot

Please try to reboot your networking gear (Router/Switches/etc.)

· No, the issue is still the same even after a reboot

Is there any change in behavior if you try to navigate to Roon Settings -> Library and set both Background and On-Demand Audio Analysis to Throttled or Off?

· No, the issue is still the same

Does the issue happen on multiple Roon Remotes (controllers) or just one?

· Issue happens on multiple remotes

Router Domain Name System (DNS) change

· I was able to change my router's DNS servers but it did not help

What is the operating system of your Roon Server host machine?

· Linux Server (Ubuntu, Fedora, ArchLinux...)

Timestamp of issue occurrences

· June 14th, 2026 at 2:35:38 PM — ~26 seconds

Describe the issue

Subject: Long delays between tracks — gets worse over time, reboot helps temporarily

Hi all,

I'm having a frustrating issue with track-to-track transitions and I'm hoping someone here has seen something similar.

The problem: When a song ends, there's often a long pause before the next one starts — sometimes just a second, but frequently 10–25 seconds. It happens both on natural track changes and when I manually skip to the next track. There's no obvious pattern to it — it's not tied to any particular album, file, or format.

What I've noticed: Right after I reboot the machine, everything is fast and snappy. But as the days go by it gets slower and slower, and after 3–4 days it's so bad I have to reboot again to make it usable. So a restart fixes it, but only temporarily — it always creeps back.

My setup:

Roon Server running on a GentooPlayer NUC (Intel i5)
Plenty of free RAM, CPU is not maxed out under normal use
My library is not huge and the play queue/playlist is small
Things I've already checked / ruled out:

It's not a bitrate or format issue — happens with everything, from low-res to hi-res, all formats
My network is rock solid — wired/strong WiFi, no drops
Internet is fast (500+ Mbps both ways, tested)
DNS is properly configured and resolves quickly
I've gone through the Roon settings and tried adjusting things there, but nothing in Roon's settings made a difference
The fact that a reboot temporarily fixes it, and then it degrades over days, makes me think something is slowly building up over time rather than a fixed configuration problem.

Has anyone experienced this kind of "fast after reboot, slowly degrades over days" behavior with track transitions? Any ideas on what could be accumulating, or what logs/settings I should look at?

Thanks in advance!

Describe your network setup

My network is wired wherever possible and has been stable and fast for a long time — no drops, no congestion.

ISP: SBB, speed 1000/500 Mbps fiber] — consistently measures 940/500+ Mbps down/up
Router/Gateway: Mikrotik + ISP-provided unit
Switch(es): lhy + tplink
WiFi / range extenders: __
All links are gigabit, and DNS is configured and resolves quickly (low latency).
Devices relevant to Roon (all on 192.168.1.x, same subnet):

Roon Server — GentooPlayer NUC (Intel i5) — 192.168.1.35, wired
Roon Bridge endpoint — Raspberry Pi 4 (GentooPlayer) — 192.168.1.14, wired
Streamer — Allo DigiOne (Raspberry Pi 4) — 192.168.1.57, wired
Remotes — desktop PC (192.168.1.10) and Galaxy S24 Ultra phone (192.168.1.22) over WiFi (WiFi speedtest 500/500 Mbps)
Everything sits on a single flat subnet, no VLANs isolating the audio devices. Network has never shown instability during the delays — the pauses happen even when nothing else is using the network.

3

Hello @Zeljko_Naumovic1,

Thank you for the detailed and well-structured report - the pattern you describe (fast after reboot, gradually degrades over 3-4 days) is very useful for diagnosis.

To investigate further, could you please upload your Roon database to our File Uploader? You can find the database location here: Database Location. Please let us know once it has been uploaded.

4

Hi, and thanks for looking into this!

I’ve uploaded the files you requested to the File Uploader:

Attached:

  1. RoonServer_db_20260615.zip — my Roon database (the Database, Settings and Logs folders). I left out the Cache folder (artwork thumbnails, ~1.4 GB, regenerable) to keep the upload size down — just let me know if you need that too.

  2. roon_stall_loglines_20260615.txt — a filtered list of [library] endmutation times I pulled from the server logs. Normal transitions are ~150–200 ms, but you’ll see the same operation repeatedly taking 25–28 seconds throughout the day. These line up exactly with the audible gaps I hear between tracks.

Quick recap of the problem:
When one track ends, there’s often a long pause before the next one starts — sometimes 1 second, but frequently 10–25 seconds. It happens both on natural track changes and when I skip manually, with no pattern as to which track.

The most telling part: right after I reboot the machine everything is fast and snappy, then it gradually degrades over 3–4 days until the gaps are so long I have to reboot again. A restart fixes it, but only temporarily — it always creeps back. This makes me think something is slowly building up on the server over time rather than a fixed misconfiguration.

My setup:

  • Roon Server running on a GentooPlayer NUC (Intel i5)

  • Endpoint chain: NUC (Roon Server) → Raspberry Pi 4 (Roon Bridge) → Allo DigiOne streamer, all wired

  • Plenty of free RAM, CPU not maxed under normal use

  • Library is not large, and the play queue is small

Things I’ve already ruled out:

  • Not a streaming-service backend issue — it happens on both Qobuz and Tidal equally. Since two independent services show the identical behavior, and a reboot of my server temporarily fixes it, the cause has to be on my side, not theirs.

  • Not bitrate/format related — happens with everything, all resolutions and formats.

  • Network is rock solid — fully wired audio chain, no drops, gigabit throughout.

  • Internet is fast — 500+ Mbps both ways, tested.

  • DNS is properly configured and resolves quickly (low latency).

  • I went through the Roon settings and tried adjusting things there — nothing in Roon’s own settings made any difference.

Exact timestamps of observed stalls (local time, CEST):

  • June 14th, 2026 — 1:28:19 PM (~27 s)

  • June 14th, 2026 — 1:36:32 PM (~27 s)

  • June 14th, 2026 — 1:43:53 PM (~27 s)

  • June 14th, 2026 — 2:00:16 PM (~26 s)

  • June 14th, 2026 — 2:06:10 PM (~26 s)

  • June 14th, 2026 — 2:15:13 PM (~26 s)

  • June 14th, 2026 — 2:35:38 PM (~26 s)

  • June 14th, 2026 — 9:02:35 PM (~8 s)

  • June 14th, 2026 — 9:02:55 PM (~4 s)

  • June 14th, 2026 — 9:58:18 PM (~22 s)

  • June 14th, 2026 — 10:00:45 PM (~25 s)

(The full list, including all the smaller ones, is in the attached .txt.)

Happy to run any diagnostics, grab more logs, or test anything you suggest. Thanks again for the help!

5

Update — I found a workaround that completely eliminated the problem (would appreciate Roon’s input)

Quick follow-up in case it helps others, and in case the team wants to look into it.

I noticed the stalls got worse the longer the server had been running and reset after a reboot — which pointed at something accumulating in memory over time. RoonServer on Linux runs on .NET, and by default .NET uses Workstation GC. My working theory was that as the managed heap grows, a blocking garbage collection was stalling playback (the pauses scaled with heap size and uptime).

As a test, I started RoonServer with Server GC enabled:

DOTNET_gcServer=1

DOTNET_gcConcurrent=1

The result has been clear-cut. Before/after, measured from the server logs ([library] endmutation times — normally ~150 ms, but the gaps I heard showed up as multi-second values):

  • Before (Workstation GC): dozens of stalls per day in the 25–28 second range, growing as the heap grew.

  • After (Server GC): ran for 29 hours straight, heap grew to ~2.8 GB, and there were zero stalls ≥3 s — every transition was 11–57 ms. The stalls did not come back as the heap regrew, which is what convinced me it’s GC-related rather than just the reboot.

I’m not claiming to know the exact internal mechanism, but the before/after is unambiguous on my system, and Server GC moving collections onto dedicated threads is consistent with it.

My question for the team: Is there a specific reason RoonServer ships with Workstation GC on Linux rather than Server GC? Would enabling Server GC by default (or exposing it as a supported option) be something you’d consider? It would be great to get this fixed upstream so others don’t have to set an environment variable manually.

Happy to provide more logs or test anything. Thanks!

6

Hi @Zeljko_Naumovic1,

Thank you for the excellent follow-up - this is exactly the kind of detailed analysis that helps us improve Roon for everyone.

Your diagnosis is spot on. This is a known area of active development on our end, and improvements to memory management and garbage collection behavior are already in the pipeline for an upcoming release. We expect these changes to address the root cause you’ve identified.

In the meantime, the workaround you found (DOTNET_gcServer=1) is a valid approach and we’re glad it’s working well for you.

After the next Roon update, please check if the issue persists without the workaround. If it does, feel free to update this thread or open a new one and we’ll continue from there. But we’re hopeful the upcoming changes will take care of it.

Thanks again for the thorough investigation - it’s genuinely appreciated!

7

Hi @Zeljko_Naumovic1,

We are still working on the next release, but once it is out, please let us know how your experience is using it, thanks!

10

Hi @Zeljko_Naumovic1,

Apologies that this thread timed out in the meantime.

We’ve released a new build (2.70) that includes some memory and performance improvements mentioned above. Have you experienced these symptoms after updating?