Track Transition Delays and iOS Remote Lag After Uptime (ref#9R5EXX)

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

· Yes, rebooting helps, but the issue returns after some time

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

· I have logged precise timestamps across two uptime cycles. All times are local (Pacific). Cycle 2 (most recent, cleanest data): First severe stall: June 11, 2026 at 12:33 AM — a track-change commit hung 25.7 seconds. Worsened to: June 11, 2026 at 12:50 AM — 52.4 second hang. Heavy cluster: June 11, 2026 between 4:03 AM and 4:22 AM — repeated 19–22 second hangs during the nightly background metadata refresh. Continued until I restarted at June 11, 2026 ~7:38 AM (final stalls at 7:21 and 7:26 AM, ~33 seconds each). Cycle 1 (earlier occurrence): First severe stall in available logs: June 4, 2026 at 4:31 PM — 20.2 second hang. (The degradation likely began earlier that day, but logs before ~2:39 AM on June 4 have rotated out.) The pattern: the server was last restarted June 8, 2026 at 5:32 PM; the first severe stall appeared ~55 hours later (June 11, 12:33 AM). In the prior cycle the server started June 1 at 9:22 AM and the first severe stall I can still see was ~79 hours later. So the issue surfaces after roughly 2–3 days of uptime and worsens until a restart. I have monitoring in place and can capture the next occurrence live with diagnostics enabled — just let me know if you'd like me to flag the exact moment when it next happens.

Describe the issue

After a couple of days of uptime, track changes start dragging. Two things accumulate together: the actual transition between songs (a growing gap before the next track starts), and the now-playing/lyrics on every remote (which sit on the previous track for up to a minute). Continuous playback within a track is fine — it's the per-track-change library commit that hangs. The iOS remotes become basically unusable. A full RoonServer restart fixes it instantly; then it slowly rebuilds and recurs.

Describe your network setup

- RoonServer on bare-metal Ubuntu, i7-6700, 32GB RAM, database on SSD. v2.67 (build 1661), linuxx64.
- 16,405-track library, TIDAL integrated (hi-res tier).
- Wired gigabit. Host verified healthy — CPU, RAM, disk, network all fine.

2

Hey @Jorge_Arias_Velasque,

Thanks for writing in and for sharing your report!

Your symptoms align directly with memory-related work our development team is on the cusp of releasing. These optimizations should immediately help you with the slow degradation over time.

Until then, the best workaround would be to perform a safe, daily reboot of your Roon Server until the next Roon Production Update is released.

Thank you! :folded_hands:

3

Adding the diagnostic detail and log evidence — I’ve done fairly deep analysis on this and it points to a server-side library-commit issue that accumulates over uptime. The signal is [library] endmutation times in the RoonServer log climbing from <0.1s to 20–80s over ~2–3 days.

WHAT I’VE RULED OUT

  • Heap/GC: flat and healthy this cycle (peak managed ~4.3GB, GC% linear, pauses mostly <500ms). Not memory.
  • Disk: zero I/O errors.
  • RocksDB/dbperf: flushes normally sub-100ms; the few multi-second ones line up exactly with the commit-stall windows — same contention, not a disk fault.
  • Remote calls: library metadata-identify calls stayed ≤~4s. The only genuinely slow remote calls were Roon Radio “mixes” recommendations (8–27s), a different subsystem that doesn’t touch the commit path.
  • Load is an accelerant, not the cause: a skip-heavy Roon Radio queue produces the most commits and surfaces the stalls fastest, but the degradation is present during normal listening and keeps worsening while near-idle (only 4 track-changes across the 04:00–07:20 window, yet that’s where the worst stalls clustered).
  • Only a real process restart clears it (GC% resets to ~0, memory fresh) — not a GC pass.

EVIDENCE (verbatim from logs)

[1] Same workload, day 1 vs day 3 of one uptime cycle — the cleanest proof it’s uptime, not load. The nightly ~04:00 metadata refresh produces background mutations of ~7–8k changed objects. Identical work, ~14× slower after 3 days:

06/09 (day 1): mutation 7622 changed objects → endmutation in 1340ms
06/09 (day 1): mutation 6983 changed objects → endmutation in 1214ms
06/11 (day 3): mutation 8131 changed objects → endmutation in 19042ms
06/11 (day 3): mutation 8415 changed objects → endmutation in 22375ms

[2] Bimodal distribution — commits are either fast or wedged, almost nothing in between:

06/10 21:05:19 [library] endmutation in 68ms
06/10 21:05:32 [library] endmutation in 69ms
06/11 00:50:57 [library] endmutation in 52389ms
06/11 04:03:22 [library] endmutation in 19042ms
06/11 07:26:36 [library] endmutation in 33791ms

[3] “Released together” — a 19s-old commit and a fresh sub-second commit finish in the same second, i.e. both blocked on one lock and freed simultaneously:

06/11 04:03:22 [library] endmutation in 19042ms
06/11 04:03:22 [library] endmutation in 416ms
06/11 04:03:23 [library] endmutation in 296ms

(Two more identical pairs: 04:04:13 → 19276ms + 553ms, and 04:13:22 → 19821ms + 653ms.)

[4] A restart clears it — GC% (cumulative since start) and memory reset, confirming the fix is a genuine process restart:

before: 06/08 17:32:56 [stats] 4528mb Physical, 2881mb Managed, 7.58% runtime in GC pauses
after: 06/08 17:33:02 [stats] 178mb Physical, 18mb Managed, 0.96% runtime in GC pauses

[5] Recurrence interval (restart → first >=20s stall):

Cycle 1: start 06/01 09:22 → first >=20s stall 06/04 16:31 (~79h)
Cycle 2: start 06/08 17:32 → first >=20s stall 06/11 00:33 (~55h)

So onset is ~2–3 days of uptime. (Logs before 06/04 02:39 in cycle 1 are rotated out, so 06/04 16:31 is the earliest >=20s I still have; the run was clean before that.)

Both cycles also had a ~16,120-track full-library metadata refresh fire at ~04:00. But the degradation precedes it (cycle 2 had 20s+ stalls at 00:33, hours before the 04:03 refresh) — so the refresh looks like a heavy burst that exposes an already-degraded lock, not the origin. The degradation itself tracks uptime.

Questions:

  1. Has anyone seen [library] endmutation climb like this over uptime? Does it correlate with library size or the nightly full-library refresh?
  2. Is there anything short of a restart that addresses it — would a database rebuild or clean re-identify break the cycle, or is a scheduled restart every couple of days the only workaround for now?

I have monitoring running and can catch the next occurrence live with diagnostics enabled — happy to flag the exact moment and pull whatever your team needs. Full logs and per-cycle distributions available on request.

4

Hi @Jorge_Arias_Velasque,

From the evidence, you’re describing a fairly well-trodden issue that users are actively discussing with Development over in Early Access. Our recommendation would be to follow the instructions here to migrate your server and remotes to the Early Access category to test some recent work our Development team has released:

https://help.roonlabs.com/portal/en/kb/articles/roon-early-access-program#

https://community.roonlabs.com/t/earlyaccess-roon-2-70-build-1665-is-live/321487/2