Initial test after changing Kitchen from RoPiee to Mac mini stopped after 1d 13h 6m 56s due to “Too many dropouts”
The Kitchen Mac mini is also the one we use for the home cinema so stopped the next test to watch some video.
Started streaming again and it stopped after 49s “Track Stopped Due to Error”
Restarted and it’s now streaming again.
Will update again if it continues for 2 days or falls over again!
What is becoming clear is that there are various technical reasons for the streaming radio service to drop out.
As a consumer of the service, I don’t care about these problems, I just want it to keep doing what I asked, which is play streaming radio until I tell it to stop. If it stops without me asking then it has failed and I’m unhappy.
I note that every time it drops out, all I have to do is click on the play button again and it usually successfully starts playing again. That could be only a few seconds after the system has stopped.
So my request is that the Roon system should be a lot more tolerant of the various “too many dropouts” or “client refused connection” type errors. The system should not give up. It should tell the user there is a problem but should keep trying to reinstate the streaming service until the user tells it to stop.
As a Systems Engineer by profession, I am convinced that any entertainment system should keep on trying to do what the user last requested. It might have to shut down for a while because of some technical problem but should resume when that problem has gone away. Once a system has stopped, the user will notice and complain. If the system hiccups and resumes the users will be much less likely to complain, they may not even notice!
It is different for safety critical systems where the system restarting unexpectedly could be hazardous e.g power tools or airport luggage belts. But there is no way Roon can be considered personally hazardous!
Hi @Adrian_Berry,
We quite agree. There’s a ticket in the pipeline to extend the retry interval for live radio so dropouts don’t interrupt playback as easily. This would more closely resemble Roon’s own download service for streaming or local playback, which has a robust retry mechanism, with a few exceptions:
Roon will always be subject to the network’s ability to reach and resolve the URL addresses for HTTP streaming reliably. Significantly, there is no local caching, so if a request continues to fail, the audio stream must eventually stop once the last received segment is played. Finally, ff the station makes changes to their URL, their broadcasting, etc., Roon also can’t adapt to these in real-time.
We’ll request a status update on the aforementioned effort to extend HLS retry intervals. Please stand by and we’ll share more information here.
After many days running and several system configurations, including doing A - B - A tests. I can now conclude;
3 RoPiee endpoints drops out after a variable period of time - a few seconds to over a day.
2 Ropiee endpoints and a single Mac mini endpoint drops out after a variable period of time - a few seconds to over a day.
1 RoPiee endpoint and 2 Mac mini endpoints does not drop out - streamed non stop for nearly 3 days before I manually terminated the streaming radio session.
The start of the shutdown is a log file message saying “Lost client connection” or “failed to connect Connection refused”.
I think it’s always the RoPiee with the lowest IP address causing the “Lost client connection” issue. Swapping physical locations makes no difference, it is the lowest IP that causes the problem.
I wonder if the RoPiees are trying to talk to each other and missing Roon Server requests?
Hi @Adrian_Berry ,
That’s an interesting observation. If you try to set Reserved IP address in your router for the Ropieee’s does that change anything?
Tried the obvious next combination; I replaced the final RoPiee with a Mac mini. It streamed for 0d 1h 45m 14s before dropping out with the “lost client connection” message.
So I now have no ideas about why the system keeps on falling over with the same error messages.
Am I expecting too much for Roon to be able to play internet radio continuously without dropping out? But Safari can do it so why not Roon?
I’ll have a look over the weekend. But given everything else I’ve tried so far, including completely rebuilding all the RoPiees from scratch and now sequentially replacing all of them with Apple Macs (which is where I started off back in January this year) and getting the same failures, I don’t think it will make any difference. It might change the physical device that causes the problem but will not eliminate the root cause.
It feels to me like Roon or RoonBridge is getting hung up in some way. Because when it drops out, Roon has been trying for several seconds to re-establish the connection. It has 5 goes and then gives up. But if you immediately restart by clicking on the play button, the system quite happily starts playing and will continue for hours. It’s got into some dead end loop.
My whole system is hard wired with CAT5e cable. I’ve tried all sorts of different wiring arrangements, missing out switches etc. All to no avail, it still drops out. I’m sure that if I had all 3 endpoints sat side by side next to my router and connected up with 0.5m cables, it would still drop out. Hmm, might try that over the weekend!
Update:- 10/05/2025 09:28 BST set the Router to use fixed IP addresses for all the Roon devices
Hi @Adrian_Berry,
Thanks for all the additional details above!
Let us know how it goes with setting fixed IPs 
After 1d 18h 2m 2s the system fell over again. I got:
05/12 19:03:56 Trace: [raatserver] [RaatServer Kitchen-Mac-mini @ 192.168.1.249:9200] client connection failed. Giving up
Followed a few lines later by:
05/12 19:04:02 Warn: [streammediafile] error reading stream: Unable to read data from the transport connection: Software caused connection abort.
05/12 19:04:02 Trace: [HIFI DSD] [raatclient] GOT [43] {“status”:“Ended”}
05/12 19:04:02 Trace: [HIFI DSD] [raatclient] GOT [45] {“status”:“Success”}
05/12 19:04:02 Info: [audio/env] [zoneplayer] All streams were disposed
I tried simplifying the system. I replaced the Office Mac mini with an endpoint on the Rock Server. I moved the HIFI DSD to a USB port on Rock and configured it the same as on the Mac mini (and RoPiee before that).
It ran Ok for over a day, then I got notified that a ROON update was available. So I manually stopped ply and installed the ROON update. I’m now running 2.52 build 1534.
Roon’s behaviour to a dropout has definitely changed. Instead of stopping completely, it waits a few seconds and retries. Which is great.
Unfortunately it has not cured the underlying failure of
05/14 11:32:01 [Local 05/14 12:32:01] Trace: [raatserver] [Bifrost Gen 5] client connection failed. Giving up
It now just keeps re-occuring.
It is now always the Lounge Mac-mini running RooBridge giving the failure. But I’ve just noticed that its WiFi is turned on as well as the hardwired ethernet connection. I’ll try turning the WiFi off.
No, that didn’t help. The system is still dropping out for a few seconds then continuing. But the Lounge system is not playing anything at all 
Trying re-booting it now.
Lounge Mac mini rebooted and without doing anything else, its back in the group and playing.
Update: 2d 9h 30m 34s days later it has stopped. There seem to be 3 significant messages in the log:
05/16 20:54:34 [Local 05/16 21:54:34] Warn: [rnet/RnetJsonClient] failed to connect No route to host
05/16 20:54:42 [Local 05/16 21:54:42] Warn: [zone Kitchen Mac + Bifrost Gen 5 + Roon server] Track Stopped Due to Slow Media
05/16 20:56:04 [Local 05/16 21:56:04] Warn: [remoting/remotingprotocolv2] stealing a perfectly good connection…hmmm
Anyway, as it played for over 2 days, which was my criteria for success, I was going to stop the experiment and go back to turning things off at night.
But when I started the steam again, it play for a second, stopped and then would not start. But eventually it restarted! So I’ve left it running again. Then discovered that the Office and Kitchen endpoints in the group are playing but the Lounge is totally silent; even though the Roon HMI says it is in the group and playing.
Update:- rebooted the Mac in the lounge, Roon started playing again but stopped in the lounge some hours later. So now I’ve tried reverting to trying a RoPiee again as the Lounge endpoint. Its been running for 18 hours 49 minutes so far.
Hi @Adrian_Berry,
Thank you for your patience. We’d like to provide some illumination on what’s happening here after reviewing logs.
- Port issues with the MacOS 10.16
LoungeRoonBridge instance.
Roon is attempting to contact the RAAT instance on the Lounge computer, but the port being reported is 0, which is invalid. Here’s the key trace:
[raat/tcpaudiosource] connecting to 192.168.1.237:0
This suggests the RAAT process on that machine either:
- Crashed and didn’t restart cleanly, or
- Failed to advertise its audio port properly, potentially due to mDNS issues or a firewall blocking discovery.
When grouped playback involves an endpoint in this broken state, playback will fail for the entire group. If playback only stops on the MacOS instance Lounge, then it might mean that there’s an issue between Apple coreaudio and RAAT on that specific machine.
- Slow Media and Dropout Threshold Exceeded
Roon attempts to stream the AAC content but encounters repeated segment fetch failures. Specifically, more than 3 seconds of audio are dropped in a 30-second window — this exceeds Roon’s threshold for acceptable stream continuity. As mentioned above, we have a ticket to investigate a more robust retry interval.
Warn: [zone ...] Track Stopped Due to Slow Media
Roon tries to re-request the segments here, but the added retry load causes the buffer to fall further behind, eventually resulting in a playback stop. This is affecting the Lounge endpoint specifically.
- CDN Behavior and Stream Robustness
This error:
error reading stream: Unable to read data from the transport connection
…usually indicates that the server or CDN has terminated the long-lived TCP connection. This is common behavior for streaming CDNs when using persistent connections without periodic keepalives or retries.
Safari handles these cases better, likely due to Apple’s AVFoundation framework, which implements robust retry and buffering logic for HLS and AAC. Roon’s streaming engine is designed to balance bandwidth with Zone distribution - it’s more sensitive and less forgiving when these disruptions occur.
To summarize, there are three vulnerabilities you’re encountering here, one of which Roon devs can attempt to directly improve with a ticket:
- A malfunctioning endpoint buffer (
Lounge) breaking group playback. This is possibly a RAATServer crash. - A stream that drops segments under network pressure, tripping Roon’s playback safety thresholds. This is what we can try to improve by adjusting the retry interval for HLS/AAC/m3u8.
- CDN behavior that severs connections after long sessions — which browsers tolerate better than Roon does.
I’ve looked up the various TLAs you used and your conclusions seem to make sense. So I look forward to the fix Roon can do.
Incidentally, after changing the Lounge Mac mini for a RoPiee, the system ran for nearly 3 days before falling over with the familiar message “connection refused” but this time from the RoPiee. After I pressed Play, the system ran for a while then stopped again. Then it refused to start. Next time it was the Kitchen Mac mini that refused connection. So I suspect that there is something in there that is not recovering after certain dropouts.
I think we have now got to the point where the issues are understood so I am going to cease the streaming experiments. My other half will be pleased to get a different selection of music!
Hi @Adrian_Berry,
We’ll certainly share the above information with our team, but to set proper expectations on a timeline for a fix, progress will likely be on the slower side, so if this ticket closes before we follow up, please know once any updates or new information is shared, we’ll re-open the thread and keep you in the loop.
Thank you!