Hi! What’s not quite right with Roon?
· None of the above quite fits
None of the above quite fits
· App interface looks or behaves oddly
Tell us what's going on
· Subject: Nucleus One — RoonServer terminating silently at ~2.95 GB RSS, twice in one day
Hardware: Nucleus One, serial #30560F907B62
Roon OS 2.1 (build 271) · Roon Labs Software 1.0 (build 18) · RoonServer 2.71 (build 1683)
Library: 31,198 tracks, watched folder \\192.168.0.4\Music_Master (Synology DS1522+, SMB, wired GbE)
Internal storage: 94% of 86 GB free
RoonServer terminated silently twice on 22 August 2026, under quite different workloads, at almost exactly the same memory figure. I'd like your view on whether this is a known ceiling, a leak, or a library-size problem.
INCIDENT 1 — 14:04 local
No bulk import. A Qobuz stream was playing with routine library activity only. Appliance had been up 19 days. Final logged memory: 2,945 mb. The log simply ends — no shutdown sequence, no exception, no FATAL.
RoonServer auto-restarted at 14:15:55, about 11.5 minutes later. I restarted it manually at 14:17:02 before realising it had already recovered.
INCIDENT 2 — 17:54:42 local
Mid bulk import: 24 albums of AIFF copied to the watched folder. Memory sat flat at roughly 2,500 mb for six minutes, then climbed 455 mb in ninety seconds, then the log ends. Final figure within 11 mb of Incident 1.
CONTROL
The session containing my manual restart logs an explicit SIGTERM. So a properly-stopped RoonServer does say so — which means the silence in both terminations above is a positive finding rather than missing evidence.
APPLIANCE-WIDE STALL
During the second event I observed the box from outside between roughly 17:58 and 18:05. ICMP replied normally throughout. TCP connections to both 445 (SMB) and 80 (web admin) were accepted and then served nothing. Two independent services mute while the kernel stayed responsive — so the fault was appliance-wide, not confined to RoonServer. The web admin UI had also taken about a minute to render during the first incident. A power cycle cleared it; everything came back healthy and RoonServer started on its own.
EXCLUDED
- Network: switch port link_down_count is 0, wired link continuous for over three days, zero errors, zero drops.
- Storage: SMB sessions to the NAS were established throughout; no storage or SMB errors in the logs. The only network errors logged were to public Roon Labs addresses during an unrelated WAN latency episode.
- Disk space: 94% free.
- Database: reports OK, and the import completed across both stalls — 30,827 to 31,198 tracks, all 24 albums present, nothing lost or corrupted.
WHAT I'M ASKING
1. Is there an expected RSS ceiling for RoonServer on Nucleus One? A hard wall at ~2.95 GB for a single process suggests a 4 GB machine to me, but I'm inferring that rather than reading it — could you confirm the RAM fitted?
2. Is a 31,198-track library within the supported envelope for Nucleus One? Incident 1 reached the ceiling with no import running, so bulk import looks like an accelerant rather than the cause. If ordinary operation is already at the limit, smaller import batches will only reduce the frequency.
3. Is there a known memory leak or regression in 2.71 (build 1683)?
I have four RoonServer logs covering both incidents, including the memory curves and the SIGTERM control session, preserved off the appliance. Happy to attach them or run a diagnostics upload — just say which you'd prefer.
Tell us about your home network
· all unifi
