Roon Live Radio playback stops intermittently on Mac mini setup (ref#S664N6) [Ticket In]

Hey @Adrian_Berry,

Thanks for following-up and sharing your latest report, sorry to hear your playback issues are still occurring.

We were able to review a fresh diagnostic report from your ROCK, and saw the following stoppages:

Trace: [.NET ThreadPool Worker] [Bifrost Gen 5] [raatclient] GOT [7] {"samples":24000,"status":"Dropout"}
Trace: [.NET ThreadPool Worker] [HIFI DSD] [raatclient] GOT [7] {"status":"Dropout","samples":24000}
Warn: [Worker (6)] [Front Office DSD + Kitchen DSD + Lounge BiFrost] [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
Trace: [Worker (6)] [Front Office DSD + Kitchen DSD + Lounge BiFrost] [zoneplayer/raat] too many dropouts. stopping stream
Trace: [Worker (6)] [Front Office DSD] [LowQuality, 24/48 MP3 => 24/48] [100% buf] [PLAYING @ 115:19] Your Decision - Alice In Chains
Trace: [Worker (6)] [Front Office DSD + Kitchen DSD + Lounge BiFrost] [zoneplayer/raat] Endpoint HIFI DSD State Changed: Playing => Prepared
Trace: [Worker (6)] [HIFI DSD] [raatclient] SENT [3353]{"request":"end_stream"}
Warn: [Broker:Transport] [zone HIFI DSD + HIFI DSD + Lounge BiFrost] Track Stopped Due to Slow Media
Info: [Worker (3)] [audio/env] [zoneplayer] All streams were disposed

However, from what we can tell, the upstream buffer from the live radio station to your ROCK stays at [100% buf] which points to the dropouts occurring somewhere between your ROCK and endpoints.

While it may be a bit tedious, I would test out playing audio to each endpoint individually to see if there is an outlier that could be causing the rest of your grouped zones to fail.

Let me know if this is at all possible, and we’ll be on standby for your reply! :+1:

Ok, I will try running with just 1 output. I’ll try all 3 individually.
I’ll update when I have some results :slight_smile:

Hi @Adrian_Berry,
Great, we’ll be on the look out for the results of trying only one output!

Hi,
Results so far:
Lounge ran for 2 days 10 hours and 49 minutes without any problems that I noticed
Kitchen ran for 2 days 3 hours and 37 minutes without any problems that I noticed
Front Office has been running for about 1 day 1 hour and some minutes. I’ve been in the office working for several hours with listening to the system. But about an hour ago, I started getting hiccups in the playback.
I’ve checked the Roon Server log file and am seeing these messages:

04/16 14:33:38 Trace: [Broker:Transport] [Front Office DSD] [LowQuality, 24/48 MP3 => 24/48] [100% buf] [PLAYING @ 1506:01] Show Me A Leader - Alter Bridge
04/16 14:33:39 Trace: [.NET ThreadPool Worker] [HIFI DSD] [raatclient] GOT [1639] {"samples":3531,"status":"Dropout"}
04/16 14:33:39 Trace: [Worker (5)] [Front Office DSD] [zoneplayer/raat] sync HIFI DSD: realtime=581794121323167 rtt=500us offset=491430223323us delta=-425us drift=-108488us in 90362.889s (-1.201ppm, -4.322ms/hr)
04/16 14:33:42 Trace: [.NET ThreadPool Worker] [HIFI DSD] [raatclient] GOT [1639] {"samples":2091,"status":"Dropout"}
04/16 14:33:43 Trace: [.NET ThreadPool Worker] [HIFI DSD] [raatclient] GOT [1639] {"samples":960,"status":"Dropout"}
04/16 14:33:43 Trace: [Broker:Transport] [Front Office DSD] [LowQuality, 24/48 MP3 => 24/48] [100% buf] [PLAYING @ 1506:06] Show Me A Leader - Alter Bridge
04/16 14:33:43 Trace: [.NET ThreadPool Worker] [HIFI DSD] [raatclient] GOT [1639] {"samples":91,"status":"Dropout"}
04/16 14:33:47 Trace: [.NET ThreadPool Worker] [HIFI DSD] [raatclient] GOT [1639] {"samples":4411,"status":"Dropout"}
04/16 14:33:48 Trace: [Broker:Transport] [Front Office DSD] [LowQuality, 24/48 MP3 => 24/48] [100% buf] [PLAYING @ 1506:11] Show Me A Leader - Alter Bridge
04/16 14:33:48 Trace: [.NET ThreadPool Worker] [HIFI DSD] [raatclient] GOT [1639] {"samples":1851,"status":"Dropout"}
04/16 14:33:50 Trace: [.NET ThreadPool Worker] [HIFI DSD] [raatclient] GOT [1639] {"samples":3851,"status":"Dropout"}
04/16 14:33:50 Info: [7] [stats] 8140mb Virtual, 2889mb Physical, 1185mb Managed, 448 Handles, 80 Threads
04/16 14:33:53 Trace: [Broker:Transport] [Front Office DSD] [LowQuality, 24/48 MP3 => 24/48] [100% buf] [PLAYING @ 1506:16] Show Me A Leader - Alter Bridge
04/16 14:33:57 Trace: [.NET ThreadPool Worker] [HIFI DSD] [raatclient] GOT [1639] {"samples":2091,"status":"Dropout"}
04/16 14:33:58 Trace: [.NET ThreadPool Worker] [HIFI DSD] [raatclient] GOT [1639] {"samples":6491,"status":"Dropout"}
04/16 14:33:59 Trace: [Broker:Transport] [Front Office DSD] [LowQuality, 24/48 MP3 => 24/48] [100% buf] [PLAYING @ 1506:22] Show Me A Leader - Alter Bridge
04/16 14:34:03 Trace: [.NET ThreadPool Worker] [HIFI DSD] [raatclient] GOT [1639] {"samples":5531,"status":"Dropout"}
04/16 14:34:04 Trace: [Broker:Transport] [Front Office DSD] [LowQuality, 24/48 MP3 => 24/48] [100% buf] [PLAYING @ 1506:27] Show Me A Leader - Alter Bridge
04/16 14:34:05 Info: [7] [stats] 8140mb Virtual, 2889mb Physical, 1186mb Managed, 448 Handles, 81 Threads

But the system has not actually stop playing.

N.B. I have not yet applied yesterdays software update.

Update: Quite a few hours later, I accidentally stopped Front Office but then immediately restarted it. Checking the log file, up until the moment. that I stopped it I was still getting the “Dropout” messages. Since starting play again 25 minutes ago, there have been no further “Dropout” messages

Hi @Adrian_Berry,

Thanks for the update! It actually sounds like things are running quite smoothly overall — playing radio for over two days straight isn’t a typical use case, so I’d love to hear more about what you’re hoping to troubleshoot.

From what you’ve shared, it seems like the Front Office zone might be the weak link in the setup. Could you share a few more details about the endpoints you’re using there, and how they’re connected (Wi-Fi, Ethernet, etc.)? That’ll help us dig a little deeper.

Hi Benjamin, what I am trying to troubleshoot is why my system drops out when streaming Live Radio. I normally have several zones grouped together. Symptoms include playing for a variable period of time then stopping for a second, restarting and immediately stopping completely. All this is explained in the posts above.
Your previous post on 9th April, asked me to run a single endpoint at a time to see what happens. Daniel’s post of 10th April says “Great, we’ll be on the look out for the results of trying only one output!”. My last post is reporting what happened. In short, Lounge and Kitchen endpoints streamed for over 2 days. Front Office developed hiccups (short dropouts) after about a day. Stopping streaming and playing again has removed the hiccups.

Here is a diagram showing the architecture of my Roon system. For clarity, I have not included all the other domestic PCs, NAS boxes and smart devices attached to the network.

I have now updated ROON to version 2.49 (build 1525) and the Raspberry Pis to RoPieee 2025.02 (2167)

I am now going to try live streaming Planet Rock with 2 endpoints in a group.

Hi @Adrian_Berry,

Apologies for any confusion in my above post - playback for two days straight without issue doesn’t sound like there are any issues there, which is great news!

Thanks for the network diagram as well. A good test would be to temporarily bypass your switches to your Front Office endpoint and see if you run into the same playback issues.

How did the above go?

Another useful test, if you temporarily swap endpoints (for example, swap your Lounge endpoint with your Front Office endpoint) do you still encounter the same results? Or, do the dropouts follow the specific device?

Hi Benjamin, it’s beginning to look like it is something to do with the Front Office endpoint. I’ve been running different groups and it always seems to be the Front Office causing a problem. Every time it starts shutting down after this message:
04/21 18:06:12 Trace: [raatserver] [RaatServer ropieeeFrontOffice @ 192.168.1.160:9200] connecting (attempt 5)
04/21 18:06:12 Warn: [rnet/RnetJsonClient] failed to connect Connection refused
04/21 18:06:12 Trace: [raatserver] [RaatServer ropieeeFrontOffice @ 192.168.1.160:9200] client connection failed. Giving up
04/21 18

I’ve already running a different cable from the NetGear GS324 directly to the Front Office Raspberry Pi, so missing out the switch. It still fell over with the same message.

I’ve just swapped over the Front Office and Lounge Raspberries so will see what happens.

Update. Well that was a disaster! I swapped Front Office and Lounge Raspberries. But the USB outputs are now, of course, swapped over as well; Front Office is feeding a Schiit Bi-Frost DAC whereas it was feeding a Douk Audio USB to Coaxial converter. And Lounge is now the other way round. The ROON system has got well confused. I’ve had to go through and rename everything. Except I can’t. Front Office now has an output named Kitchen. When I try to rename it, it won’t take it. Kitchen and Front Office seem to be conjoined: if I change the output name on one then the other changes to the same name! Aaaaaaaarrrrggggghhhhh
I’ve re-booted everything a couple of times; I’m now in the situation where in Roon >Setup > Audio I can see the 3 Raspberry Pies and they have differently named outputs :slightly_smiling_face:. But when I try to choose a different Audio Zone from the bottom bar of the ROON window, only Lounge and Kitchen are offered. Front Office is just not offered :frowning_face:
But a few minutes ago, Front Office was there and Kitchen was not. :scream:

Time to go to bed and worry about it all tomorrow. :sleeping:

Update Thanks to some help from the community,

after rebuilding all 3 RoPiee endpoints, the ROON system is now seeing all 3 endpoints correctly.

So now running all 3 in a group to see if the rebuilds have solved the original dropout problem!

If support are interested this was my report of what I suspect is the same error a few years ago.

2 Likes

This sounds like exactly the same identity crisis I was seeing. Had to rebuild all the RoPies to fix it.

I think it highlights the absence of a function in ROON to positively tell it to forget a device.

I guess it might be worth re-installing Roon Bridge.

Ropieee didn’t have that option when I last had the issue.

I suspect whatever id is duplicated is kept on the endpoint, because clearing out the ids in ROCK didn’t help.

How long will it take you to know if it resolves your issue?

About 2 days. If I can run the 3 endpoints in a group streaming Planet Rock for that long then I’ll declare the issue closed. Before these changes, I’ve had it run for a few minutes or over a day and then drop out returning the same error message. Done 1:54:25 so far!

With RoPieee you don’t need a separate installation of RoonBridge. RoPiee includes it.

1 Like

Rooiee now has an option to re-install Roon Bridge - which I guess may reset the mysterious identity.

Should have thought of that previously…

You are correct. Right at the bottom of the Advanced page.
But if you are getting these sort of confusion issues where it’s not clear exactly where the problem lies, then it’s probably worth the extra effort of reinstalling everything.

10hrs 22 minutes and still playing. So starting to look good :blush:

1 Like

Hi @Adrian_Berry,
Glad to hear that live radio is still playing as expected! Thanks for keeping us in the loop — don’t hesitate to reach out if anything changes.

Interestingly I just had an example of the duplicated identity issue.

Like you I just rebuilt both to make sure I’d solved the issue.

I guess this might be a Ropieee thing.

1 Like

Hi Daniel, yes I have made some progress. Running the 3 RoPiees in a group I am still getting dropouts, usually after over 24 hours continuous playing. This might be considered reasonable: except it was always the same RoPieee endpoint causing the stop - the one originally identified as Front Office. So I physically swapped Front Office with Lounge.
This initially caused another problem with Roon getting confused between the RoPiees (see above). This was solved with input from Greg Dowling (Profile - GregD - Roon Labs Community).

So back to the original dropout problem: again it reoccurred after more than a day’s solid running. It was the same RoPiee that caused the dropout, the one I had swapped from the Front Office to the Lounge.

I’ve now replaced the Lounge (ex Front Office) RoPiee with the vintage Mac mini that I originally used for the Lounge before moving to the RoPiees. With that grouped with the 2 remaining RoPiees, the system has now been streaming Planet Rock for 17 hours and 17 minutes. I’m waiting with bated breath to see what happens this time tomorrow!

Update: well it is now ‘Tomorrow’ and the system has just stopped playing after nearly 24 hours. Log file says:
04/27 12:21:09 Trace: [raat_ll/client] [HIFI DSD] OnDisconnected: BeginRead ead count is 0
04/27 12:21:09 Trace: [raatserver] [RaatServer ropieeeKitchen @ 192.168.1.253:9200] lost client connection. Retrying(0)
04/27 12:21:09 Trace: [raatserver] [RaatServer ropieeeKitchen @ 192.168.1.253:9200] connecting (attempt 1)

This is the start of the same dropout sequence I’ve been seeing before. Except it is a different RoPiee this time.

So now I’ll swap out the KitchenRoPiee for another Mac mini and wait.

Yes, I’m making progress with my original dropout problem. Since fixing the identity issue it’s been the same RoPiee causing the dropouts. So now waiting to see what happens after substituting a Mac mini running RoonBridge for the dodgy RoPiee

Hi @Adrian_Berry,

Thank you for such a detailed follow-up!

Since some time has passed, we wanted to check in and see how things are performing?