· Frequent problems where Roon either skips every track after less than 10 seconds, or displays message saying streaming is starting, but music doesn’t start.
Only way to consistently resolve is to reboot Mac that hosts Roon server.
I think the next step here is to enable some diagnostics on your account so our technical staff can get some more insight into what’s going on here.
However, before I enable this feature, I’d like to ask for your help ensuring we gather the right information.
First, can you please reproduce the issue once more and note the time at which the error occurs. Then respond here with that time, and I’ll make sure we review the diagnostics related to that timestamp.
We’ve been able to gather and assess logs in the meantime and have identified the dropouts you’ve described.
We see RAATServer on the Mac logging a connection failure when it attempts to initiate a TCP connection with a particular Bluesound Node2i (the Zone named Kitchen). The Node2i is initially alive on the network and advertising but its connection to Roon stalls when Roon starts to initiate playback. From what we can tell, the vulnerability here is the endpoint’s connection to the network.
Is the Kitchen Zone using WiFi or ethernet? What is the specific network pathway between the Mac Mini and that Zone? T
Try hardwiring it if it’s relying on WiFi.
The dropouts we saw were during grouped playback with several other Zones. If you play to the Kitchen Zone directly do you have any issues?
the three zones I run as a group (kitchen, living room, tv room), are all connected by Ethernet, as is my Roon server. I pretty much always have them grouped so I can’t say if the issue is present for that endpoint or its own.
Just realized I didn’t fully answer your question. Path is Ethernet from Mac to router, Ethernet from router to wall Ethernet jack, direct Ethernet cable to another jack, then Ethernet to bluesound node. I had it all professionally installed to ensure reliable AV throughout the house.
One more reply… I’ve ungrouped the zones and have each playing music independently. I’ll leave them all playing overnight and through tomorrow to see if that helps provide some further data.
The three zones ran fine overnight, but when I got home around 6:00 I found that the TV room zone had stopped playing at some point during the day. It appears to have skipped 4 tracks before stopping. I was able to restart it without rebooting the server though, so this problem seems less severe than what I have been experiencing. I am now going back to grouped zones and will advise further.
Back to issues with my grouped zones this evening. Each track plays for a few seconds then skips to the next. It appears to have been going on for quite a while with over 150 skipped tracks.
After rebooting server, music plays without skipping, but is now not coming through living room zone.
opened bluesound app to reboot living room, and observed error message in attached screenshot.
after rebooting living room, system is restored to normal operation.
Thanks for the additional information @Daniel_Rice!
From another fresh diagniostc report, we can see it clearly. The key errors are:
Failed to prepare Bluesound NODE 2i in 15000ms. Giving up and Error: while sending frames for Bluesound NODE 2i: serverside buffer overrun.
The “Failed to prepare” device and the “serverside buffer overrun” are tied to 192.168.1.157, one specific NODE 2i. This actually appears to be the Living Room zone, rather than the kitchen.
A serverside buffer overrun in grouped RAAT playback means the server is pushing audio faster than that one endpoint drains it; the slow endpoint stalls, drags down the synchronized group, and Roon abandons the track. So the symptom is “the whole group skips,” but the cause is one endpoint’s stream backing up.
Since you’d previously confirmed all three are wired, the next diagnostics should isolate the TV Room node’s path specifically:
Reframe to TV Room, not Kitchen. Play the TV Room solo for an extended period and see if there are any skips.
Check the TV Room network leg in isolation. Swap the TV Room node onto a known-good cable/port (ideally test it temporarily on the same switch port the Kitchen node uses) to see if the overruns follow the node or the cable.
Confirm BluOS are on the latest firmware.
Rule out a duplicate-IP / DHCP issue on .157. The intermittency (fine for hours, then a storm) is classic for an IP conflict or a flaky link that degrades under sustained load. A DHCP reservation for each node is a cheap ruling-out step. Let me know if you’re able to set this up.
when I tested zones ungrouped this week, I actually ran all 3 simultaneously for about 24 hours and TV room seemed to be fine. I’m not sure what you mean by reframe to tv room. Does this mean use it as the anchor for the group? I’m also not sure what you mean by swap it to a known good port, because the issues seem to affect both the other zones at different times.
with respect to DHCP reservations, I just checked and it appears I’ve already done this. See the attached picture.
firmware, I’ve been keeping the nodes up to date and confirmed they are all current.
please let me know what I can try next, but I’m not super technical so please give me clear instructions.
I’m guessing it is a note that it is the TV Room Node exhibiting the problem NOT the kitchen Node as was discussed earlier in the thread. And to focus investigation/testing on that Node.
No, you should not do that if it is the zone with issues.
He is suggesting connecting the TV Node using the same port (and maybe cable) that a currently working Node is using; he suggested Kitchen.
Ok, I’m still a bit confused about why we’re focusing on the tv room when the issues seem to be cropping up for kitchen and living room. That said, I started by replacing the Ethernet cable that tv room is using, and moving it to another port on the switch I have in the tv room. I will monitor and advise further.
Because when Benjamin looked at the logs the failures were happening…
It is interesting that your router is listing 192.168.1.156 as the Living Room IP. Using a tool like Fing, I would suggest taking a look and see if there isn’t something on your network using the IP 192.168.1.157.
Fellow user here, btw, official support is Mon-Fri.
Ethernet ports can go bad, both on the switch and sometimes on the device.
music starts skipping every track after several seconds on my group of three zones. Ungrouped and regrouped to confirm that living room plus tv room plays fine, but any grouping including kitchen does not. Rebooted kitchen
hardware. Now music playback will not start at all with message in screenshot below displaying. Rebooted Mac hosting Roon server, and system returned to normal functioning.
Thanks for the screenshot - that “Starting playback on your Audio device” message is the exact failure point we were looking for.
After reviewing your diagnostic logs we’ve identified the root cause. Your Mac is connected to the network through two active Ethernet interfaces simultaneously, and they’ve each picked up different Bluesound nodes:
Interface 1 (192.168.1.173) → Kitchen
Interface 2 (192.168.1.117) → Living Room + TV Room
When Roon’s RAAT audio engine runs a synchronized group, it needs to send perfectly timed audio frames to all endpoints from a single source. With your Mac presenting as two different hosts on the network, RAAT cannot maintain that synchronization - the result is exactly what you’re seeing: the whole group skips, and only a server reboot resets the connection state.
The fix:
Go to System Settings → Network, select Wi-Fi, and turn it off. Since your Mac is already wired via Ethernet, you won’t lose internet access. Once WiFi is disabled, all three Bluesound nodes will route through a single interface and grouped playback should stabilize.