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! ![]()
