Hi @roon - I’ve been having a really nasty problem for some time now, which I notice very clearly every day when I’m using the system. I’ve already tried to pinpoint the cause of the problem. Here are my findings. I’d appreciate some help.**

Roon Core Machine**

Linux server (Debian 12, kernel 6.12, x86_64), RoonServer installed natively as a systemd service with a dedicated data directory. Currently on 2.71 earlyaccess (build 1675); identical behavior previously on 2.70 production (build 1671).

Networking Gear & Setup Details

All devices wired Gigabit Ethernet on the same subnet. No VLANs, no WiFi involved for Core or endpoint.

Connected Audio Devices

Trinnov Altitude 32, Roon Ready (RAAT over network), firmware 4.4.3 (unchanged for months).

Description of Issue

Reproducible sequence:

Roon plays to the Trinnov zone normally.

I switch the Trinnov’s input away from Roon (optical input, watching TV for a while).

I switch back to the Roon input and start playback.

What happens then, from the Core logs:

The RAAT control channel is healthy: request_source is answered with {"status": "Success"}, the source control goes to “selected”, volume control works. But the endpoint prepare fails:

Warn: [zoneplayer/raat] Failed to prepare Trinnov Altitude32 in 15000ms. Giving up
Warn: [zoneplayer/raat] failed to setup any endpoints..giving up
Warn: [zone Altitude] Track Stopped Due to Error

Notably, the device’s audio connection (raat/tcpaudiosource) is only logged as connected roughly 20 seconds after the setup request — just after Roon’s 15-second timeout expired.

From that moment the zone is permanently unusable. Every transport action (Play, PlayPause, Next) throws:

Critical: scx: System.NullReferenceException: Object reference not set to an instance of an object.
   at Sooloos.Broker.Transport.RaatEndpointIntegration.DoSelectSource(ResultCallback cb_result)
   at Sooloos.Broker.Transport.Endpoint._SelectSource(ResultCallback cb_result)
   at Sooloos.Broker.Transport.Zone._SelectSource(ResultCallback cb_result)
   at Sooloos.Broker.Transport.Zone._PlayPause()

I also captured the Core crashing on the write path mid-playback right before such an episode:

Warn: [raat_ll/client] [Trinnov Altitude32] error writing to connection: System.NullReferenceException
   at Roon.Audio.Raat.Client._BeginWrite()

followed by repeated failed to connect(0) Connection refused against the device, whose RAAT port changes between reconnects (which suggests the device’s Roon Ready service restarts as well).

Everything I tried, in detail

Restarting RoonServer only: does NOT fix it — after a restart, the very first Play on the zone throws the same NullReferenceException again.

Stopping RoonServer, waiting 30 seconds, starting: no change.

Power-cycling the Trinnov only: no change.

Stopping RoonServer, deleting the contents of the Cache folder inside the RoonServer data directory, then starting: this initially appeared to be a reliable fix (playback worked immediately afterwards). On later occurrences, however, the broken state re-formed within about 90 seconds even with a freshly rebuilt cache — so the cache is evidently not the (only) place the broken state lives.

Disabling and re-enabling the zone under Settings → Audio: no change on the occasion tested.

Restarting RoonServer AND power-cycling the Trinnov together: this is currently the reliable recovery path.

As a mitigation I now run a small cron watchdog on the Core machine that greps the current log for the two signatures above (“Failed to prepare” / “DoSelectSource”) and then stops RoonServer, clears the cache and restarts it. This keeps the system usable for the household, but it is obviously just a band-aid.

Updating to Early Access 2.71 (build 1675): the issue is still fully reproducible there (prepare timeout at 11:57:47, NREs at 11:59:05 and 11:59:50 local time on 2026-07-20).

Interpretation / suggestion

The trigger appears to be the device being slow to bring up its audio socket after an input switch (more than 15 seconds — I will report that side to Trinnov as well). But the Core’s reaction looks like a genuine bug: after “Failed to prepare … Giving up”, the RaatEndpointIntegration object seems to be left in a half-initialized state, and every subsequent SelectSource null-derefs instead of retrying or rebuilding the endpoint. Supporting this: the zone occasionally self-heals when the RAAT connection is fully torn down and the endpoint object is recreated. A null-guard plus endpoint rebuild after a failed prepare (or a retry / longer or configurable timeout for the prepare itself) would likely make this recoverable without restarting the Core.

This setup ran for a long time without this issue; I first noticed it some weeks ago and cannot tie it to a specific version change on either side. I’m happy to provide full logs or enable diagnostics — the timestamps above should make the episodes easy to find.