Thanks for writing in and for sharing your report!
From what we can see, the Server software itself is stable, version 2.67 (build 1661), no crashes or restarts, and memory is flat (~4.8 GB physical, no leak).
What’s failing is the RAAT audio bridge. At almost exactly four-hour intervals, every audio endpoint disconnects at once with [raat/tcpaudiosource] connect failed: Connection refused, then immediately reconnects. That matches the reported symptom exactly: brief stop, all players, Roon still running, instant recovery.
The reason this points away from the network: at each event, the log shows every RAATServer losing its client connection at the same second — including RaatServer Rhein-Z1-V2 @ 127.0.0.1:9200, which is the loopback connection on the Server machine itself.
A LAN problem can’t take down a 127.0.0.1 connection. The four-hour periodicity and the loopback dropping together indicate something on the Rhein Z1 Plus (the Silent Angel / VitOS box) is cycling the RAAT service on a timer.
Let’s focus on the Rhein Z1 Plus, not the players or the LAN. Concretely:
Check VitOS for any scheduled job, watchdog, or power/eco setting that fires every four hours. Silent Angel's VitOS has had scheduled-maintenance and "auto-optimize/cleanup" behaviors; a CPU-governor or sleep/wake cycle would also explain it. This is the single most likely culprit given the precise 4h timer and the six-month onset.
Confirm the onset against a VitOS firmware update. The user says it was stable until ~6 months ago, ask whether VitOS (or the Z1 firmware) updated around then, and consider rolling back or reinstalling that firmware.
Reinstall/repair the RoonServer instance on the Z1 (or test by temporarily running RoonServer on a different machine, e.g. the Mac mini already visible in the logs as a RAATServer). If the 4-hour dropouts disappear on other hardware, it confirms the Z1/VitOS as the source.
Separately, clear two unrelated noise items that aren't the 4h cause but are worth fixing: the Cambridge Audio Evo 150 throws a constant cast/client … Unable to authenticate TLS connection loop (re-pair or disable it as a Chromecast endpoint), and there are recurring RAAT "long rtt" sync warnings on the NAD CI580 zones suggesting marginal timing, worth checking those endpoints' network path (wired vs Wi‑Fi, switch port) even though IT cleared the network generally.
Is this an enterprise IT setup? Where is the server connected relative to the other endpoints, and do you have any enterprise-grade switches in between?
Roon’s network discovery architecture assumes a fairly simple network topology and Roon relies on sustained TCP connections to all endpoints during streaming. If managed switches or other enterprise components are tightly controlling traffic, you can get unpredictability with Zone control and playback in Roon with your networked Zones.
What is the specific error message you see in Roon when these endpoints all drop out?
We have not heard back from you, so we will go ahead and close this thread due to inactivity. If you need further assistance, please submit a reopen support request via the technical support help form link and specify that the issue be reopened. Thank you.
