Roon Server has been freezing for multiple seconds at a time (ref#EGB9BK)

Support
1

What app are you having the slowness issue with?

· Roon

What kind of performance/speed issue are you experiencing?

· The app takes a long time to respond to commands

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 don't know how to do this

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

· Nucleus

Which model Nucleus do you have?

· Nucleus Rev B

Timestamp of issue occurrences

· GC pause times exploded after the update.** Scanning every `[stats]` line per day (UTC days): | Day | Max GC pause | Samples with pause > 500 ms | | ------------------------- | ------------ | --------------------------- | | Jul 8 (first day on 1671) | 7.7 s | 559 | | Jul 9 | 4.4 s | 78 | | Jul 10 | 10.3 s | 1,527 | | Jul 11 | 14.1 s | 2,652 (1,517 over 1 s) |

Describe the issue

Roon Server Machine
Nucleus Rev B (i3, 4 GB RAM), RoonOS 1.0 (build 259), Roon Server 2.70 (build 1671) — auto-updated from 2.67 (build 1661) on July 7. Music on the 4 TB internal SSD.

Networking Gear & Setup Details
ASUS RT-BE82U (WiFi 7) + AiMesh (5 nodes). Nucleus connected by Ethernet to the router. AT&T Fiber with the BGW320 gateway in IP Passthrough (no double-NAT). No VPN, no VLANs. This network has been stable with Roon for months.

Connected Audio Devices
~11 Sonos zones (Sonos streaming protocol, mix of wired/wireless) — the affected zones (Patio, Master Bedroom) are Sonos
Eversolo DMP-A6 (Roon Ready/RAAT, wired via MoCA/Ethernet)
Misc. AirPlay and Chromecast devices
Control: iPhone Roon Remote
Number of Tracks in Library
28,374 tracks / 2,693 albums (from the server's own [library stats] log line — corrected 2026-07-11; earlier "under 50k" estimate was stale)

Description of Issue
Since the 2.70 (1671) update installed on July 7, Roon Server has been freezing for multiple seconds at a time, and during those freezes Sonos zones lose their control channel: music stops mid-track, the remote app loses control of the zone, and the log shows Track Stopped Due to LostEndpoint. Over July 10–11 this happened 9 times across two Sonos zones (Patio, Master Bedroom). This never happened on 2.67 (one isolated occurrence in the whole prior week).

What the server logs show:

1. GC pause times exploded after the update. Scanning every [stats] line per day (UTC days):

Day Max GC pause Samples with pause > 500 ms
Jul 8 (first day on 1671) 7.7 s 559
Jul 9 4.4 s 78
Jul 10 10.3 s 1,527
Jul 11 14.1 s 2,652 (1,517 over 1 s)
During evening listening on Jul 11 the server logged 150–237 pauses over 1 second per hour, with maxima of 11–14.5 seconds. For comparison, the worst single pause I ever measured on 2.67/1661 on this same machine was 1.6 s. Managed heap is in the same ~1–2.1 GB range it always ran at, so this isn't simply "heap got bigger" — pause behavior is ~10× worse at the same heap size. The stats lines also now show ~680 MB Native alongside the managed heap.

Example stats line from just before a Sonos drop:

07/10 23:31:32 Info: [stats] 12816mb Virtual; 1874mb Physical = 1198mb GC-committed (1103mb Managed-live = 92% of committed) + 676mb Native; 486 Handles, 74 Threads, 1.49% of runtime in GC pauses, 1629ms GC pause in last window (10.83% of window)
2. The Sonos drops are Core-side, not network. At the moment of each drop the zone is PLAYING with a 100% buffer and Sonos UPnP subscription renewals are succeeding. The failure sequence in the log is:

07/10 23:31:22 Trace: [1 Patio] [HighQuality 41.9x, 24/96 FLAC => 24/48] [100% buf] [PLAYING @ 0:10/4:48] ...
07/10 23:31:27 Trace: [client/sonos] try renew start: urn:upnp-org:serviceId:AVTransport
07/10 23:31:27 Info: [client/sonos] try renew after renew: ... failed: False
07/10 23:31:42 Trace: [1 Patio] [zoneplayer/sonos] startstream timeout expired, state is: WaitForStatus
07/10 23:31:42 Warn: [zone 1 Patio] Track Stopped Due to LostEndpoint
Also seeing stale av status event ignored and position timer reported next url, fix for bug 16980 triggered warnings on the same zones — consistent with the server missing/handling Sonos eventing late because it's frozen in GC.

3. A daily server restart no longer keeps it healthy. I run a scheduled nightly restart of Roon Server (05:15, after the analysis window). On 2.67 that kept the machine responsive all day. On 1671, each fresh process degrades back into >1 s pauses within ~10 hours — by evening it's freezing again. The post-update library reprocessing finished by Jul 9 (audio analysis activity is near zero in the logs since), so this isn't the usual post-upgrade surge. No crashes — zero Critical lines, no xdts dumps; the process stays up, it just stalls.

Happy to send the full log set. Was 2.70's new browsing/search architecture (Tantivy etc.) validated on 4 GB Nucleus Rev B hardware?

Describe your network setup

ASUS RT-BE82U (WiFi 7) + AiMesh (5 nodes). Nucleus connected by Ethernet to the router. AT&T Fiber with the BGW320 gateway in IP Passthrough (no double-NAT). No VPN, no VLANs. This network has been stable with Roon for months.

2

Hey @John_Hill3,

Thank you for the incredibly thorough report and logs, the day-by-day GC breakdown and the timestamps saved us a lot of time, and they let us pin this down with confidence.

What we found

Your instinct was right: this started with the 2.70 (build 1671) update, and it’s happening inside Roon Server, not on your network or storage. After the update, Roon Server’s memory management on your Nucleus began pausing the whole process for several seconds at a time, by evening we see it frozen for as long as 14 seconds in a 15-second window. Every one of the Sonos dropouts (Patio and Master Bedroom) lines up exactly with one of those freezes: the zone is playing with a full buffer, then the server stalls, misses the Sonos timing/eventing, and the zone gets dropped as a lost endpoint. On 2.67 the worst pause we can find on your same machine was a fraction of a second, so this is a real change in behavior.

We also reviewed your Nucleus system logs. They’re clean in the ways that matter: no out-of-memory events, no crashes, no network-storage errors, and no operating-system-level hangs.

We’ll go ahead and escalate this to our development team for further analysis.

What can help in the meantime

None of these are a fix, but they should reduce how often you’re interrupted while we work on the real solution:

  1. Add a second scheduled Roon Server restart. Your nightly 5:15 AM restart is good, but the server degrades back into long pauses after roughly 10 hours. Scheduling a second restart an hour or so before your main evening listening window should keep it responsive when you actually use it.
  2. Clean up one network share. Your system logs show an external drive, "Crucial X9 Pro For Mac" being re-mounted roughly every 36 seconds, thousands of times a day, over the old/insecure SMBv1 protocol. This isn't the cause of the freezes (it was happening before the update too), but it's constant background work the Nucleus doesn't need. If that share is something Roon uses (a backup location or watched folder), reconfiguring it for SMB2/3 as a persistent mount, or removing it if it's not needed, will take some load off. Can you let us know what that drive is used for?
  3. Keep audio analysis throttled or off, as you already have it.
We'll follow up as soon as we hear back from the development team. Please keep the machine on your current setup for now so the logs stay consistent, and don't hesitate to send fresh logs if the behavior changes.

Thanks again for your patience and for such a well-documented report. :+1:

3

Thank you for the quick follow up. Look forward to learning more.

John

4

On your suggestions:

Second restart: Already in place. Two days ago I added a second scheduled Roon Server restart at 3:30 PM (ahead of my evening listening window), alongside the existing 5:15 AM one. Both fired cleanly today. I’ll keep both running until a fixed build ships.

The Crucial X9 Pro share: Mystery solved on my end. That’s a portable USB SSD that was attached to a Mac and shared over the network — I used it once to copy hi-res music files onto the Nucleus’s internal storage, where they still live. The stored path points at 192.168.86.84, which is my previous router’s subnet (Google Nest WiFi, replaced with an ASUS mesh in late April). So the share has been permanently unreachable since then — it’s not a backup location or active watched folder, just a stale storage entry. I’m happy to remove it from Settings → Storage now, but since you asked me to keep the setup consistent for logging, let me know whether to remove it right away or leave it untouched while development investigates.

Audio analysis: Staying throttled as-is.

I’ll keep the machine on the current setup otherwise and send fresh logs if anything changes. Thanks again.

5

Hello @John_Hill3

Thanks for confirming both of those, and for tracking down the Crucial X9 Pro share, mystery solved indeed. Since it’s been unreachable since the router swap in April and isn’t tied to any active backup or watched folder, please go ahead and remove it from Settings > Storage whenever you like, that stale entry has nothing to do with what we’re investigating for the GC pauses, so there’s no need to leave it in place for logging purposes.

One more option in the meantime: Roon 2.71 (build 1674) is live now on the Early Access branch and includes memory and performance work in this same area. If you’d like to try it ahead of the general release, you’re welcome to, no pressure either way since your two-restart workaround is holding steady. Here’s more info: EarlyAccess: Roon 2.71 Build 1674 and ARC 1.81 Build 422 are Live!

6

Hello,

Thanks for the go-ahead on both fronts. Quick status update:

  1. Stale storage location removed. The Crucial X9 Pro share is gone from Settings > Storage, so the SMBv1 remount loop you spotted should have stopped as of yesterday (7/16). Feel free to confirm on your end in the system logs.

  2. I’ve joined Early Access. I took a fresh backup first, then switched the Nucleus via the instruction file + Reinstall. By the time I updated, the EA branch had moved one build past the one you mentioned, so I’m now on 2.71 (build 1675), with my Windows remote on the same build and my iPhone on the TestFlight versions of both Roon and ARC.

One scheduling note for your log review: I’m listening normally tonight and tomorrow morning, but then I’m away from 7/18 through 7/23, so the system will be essentially idle that week — background load only, no playback. Both daily restarts (5:15 AM and 3:30 PM) are still in place and everything else is unchanged, per your request to keep the setup consistent. When I’m back I’ll report how the new build holds up during real evening listening, especially on the Patio and Master Bedroom zones.

Thanks again for the help on this one.

John

7

Hey @John_Hill3,

Most excellent, that sounds. Enjoy your travels! We’ll be monitoring for your report upon your return. :folded_hands:

8

Good news — I’m back from a week away and just went through a full week of logs on 2.71 (build 1675) Early Access. The improvement over build 1671 is dramatic.

Setup for the week (7/18–7/24): The Nucleus ran unattended with my two scheduled server restarts still in place (5:15 AM and 3:30 PM), so we got 14 separate process windows of 10–14 hours each, all on build 1675 — no config changes all week, minimal playback.

Results vs. the 1671 baseline:

  • On 1671, my worst day (7/11) had over 1,500 stats windows with more than 1 second of GC pause time, maxing at 14.1 seconds, with sustained runs of 150–237 per hour every evening. On 1675, my worst day all week had about 61 — roughly a 96% reduction — and most days were in the single digits.
  • Zero “Track Stopped Due to LostEndpoint” events all week (I had 9 in two days on 1671 — that was the symptom that started this ticket).
  • Zero crashes, and no sign of the uptime-driven degradation: on 1671 a fresh process re-degraded within ~10 hours; on 1675 every process stayed healthy through 13.7-hour windows.
  • The remaining GC activity all maps to expected heavy work: process startup (~90 seconds), the 1–5 AM background analysis window, my weekly Dropbox backup, and ARC syncing when I reconnected after vacation. Nothing during listening hours.
  • Heap looks well-behaved too: typical peaks around 0.9–1.1 GB managed-live, with the worst overnight (during analysis) reaching ~1.8 GB and recovering afterward — not the runaway growth I saw on 1671.

Next step on my end: I’ve now disabled the 3:30 PM restart, so the server will run ~24-hour processes spanning evening listening plus the overnight analysis window — the exact scenario that failed on 1671. I’ll listen normally over the weekend and report back, but based on this week’s data, whatever memory/GC work went into 2.71 appears to have fixed the regression on my 4 GB Nucleus Rev B.

Thanks again for the Early Access invite — happy to send log excerpts if useful for the dev team.

Best,
John

9

That is excellent news @John_Hill3! We’ve actually just included a fresh Early Access update that should improve things further as well.

Keep us posted on how things have been performing. :folded_hands:

10

Hello @John_Hill3 ,

We wanted to follow up and see how the system was performing with Early Access on your end, have there been any further improvements and is the system working as expected following more testing?

11

Reporting back as promised. Since my last post I disabled the 3:30 PM restart on 7/24, so the server has now spent ~2 weeks running the setup I said I’d test: a single 05:15 restart and otherwise ~24-hour processes that span evening listening plus the overnight analysis window — the exact scenario that failed on 1671. Short version: the fix is holding, and it’s held across several EA updates since (I’ve auto-updated 1676 → 1679 → 1684 in just the last few days).

Hard numbers from the current retained log window:

  • Zero crashes. No abnormal-termination artifacts at all (last one on my system is back on 5/4).
  • Zero “Track Stopped Due to LostEndpoint” events. That was the symptom that opened this ticket — none.
  • Zero Critical/unhandled-exception lines.
  • Heap stays well-behaved on the 4 GB Rev B. Managed-live typically sits ~1.0–1.1 GB during normal use, with the only real excursion (~1.56 GB) during the overnight analysis on a day that also took an EA auto-update mid-morning — and it recovered right afterward. No runaway growth.
  • All remaining GC activity maps to expected heavy work — nothing during listening. On my busiest day, the sub-second-plus GC windows clustered at 1 AM (79 of them, the background analysis window; worst single 15-s window ~8.8 s cumulative at 1:46 AM), plus the 5:15 restart startup and the post-update re-index surge. Evening listening hours were essentially clean — a handful of windows at most, nothing catastrophic. For contrast, on 1671 my evenings ran 150–237 GC pauses over 1 second per hour with single freezes up to 14 s and zones dropping. That pattern is simply gone.

So the 24-hour-process test I set out to run has passed — whatever went into 2.71 fixed the regression on my 4 GB Nucleus Rev B, and it’s stayed fixed through the last few EA builds. Happy to send log excerpts for any specific window if the dev team wants them.

Thanks again,
John