Playback dropping on multiple KEF Network Zones, especially when the devices disappear and reconnect, points us toward a network or device communication problem rather than a file-specific one.
We’d like to check a few things next:
Are the LS50 II, LS60, and LSX all on the same wired or wireless segment as your Roon Server, or are some of them connected through different Deco satellites?
When the drop happens, does the affected zone show a signal path interruption, or does it vanish from Settings > Audio the way your notes suggest?
Do you have any switches between the Roon Server and the KEF devices, or is everything going straight through the Deco system?
Given your network setup, we’d also like you to review our [url=https://help.roonlabs.com/portal/en/kb/articles/networking-best-practices]Networking Best Practices[/url] article, since it covers the kinds of discovery and stability issues that can cause playback interruptions like this.
If you can share whether the problem hits all three KEF devices equally, and whether it happens on wired playback only or also over WiFi, we can narrow this down further.
HI - i have been having issues with Roon and kefs for months. Had a previous support thread, that was thought to be due to a kef firmware update. Issue persist post several kef updates. I am also in touch with kef, and it seems there may be an issue at their end
It happens regardless of wired or wireless. It affects the LS50 most, LS60 second.
I have followed all wifi troubleshooting previously and turned off all ‘exciting’ wifi 7 features. No change. I now have run a wired backhaul between nodes to see if any different. No different when all connected on the same wired segment. I have >600Mbps throughput on all nodes when wireless. Video, TV, videocalls for work all hold up fine with no dropouts over wifi
Its a Kef and ROON issue as far as i can see
Refuses to start playing, skips many tracks then says ‘too many failures’
Thanks for the detail and for the legwork already. I’ve now been through both the RoonServer and RAATServer logs, and there’s an interesting lead I want to check with you.
Two separate things are showing up:
First, there’s a long-standing instability specific to your KEF RoonReady zones (LS50 II, LS60, LSX II, soundbar). Roon repeatedly sees the KEF drop its RAAT connection (“no data received for >10000ms, killing connection”), the zone disappears, and reconnection often times out, which is your “won’t start / skips / too many failures” behaviour. Notably ~94% of these drops happen while nothing is even playing, so it isn’t bandwidth. That part is consistent with a KEF firmware issue and lines up with what KEF has told you.
Second, and this is new, the server’s network discovery layer was stable at a baseline rate for two weeks and then on 21 July, started thrashing: rebinding its discovery socket every few minutes and logging network errors, and it’s stayed that way since. KEF drops spiked roughly tenfold the same day. That’s a network-level event, not a device one.
So my question: did anything change on your network around July 21? You mentioned adding a wired backhaul between your Deco nodes, if that went in around then, it’s worth a close look. A wired backhaul running alongside the mesh’s wireless backhaul can create a network loop or duplicate the multicast/mDNS traffic that Roon and KEF rely on for discovery, which would produce exactly this pattern. It’d be worth temporarily reverting the backhaul change to see if the discovery churn (and the drops) settle.
A couple of other things that would help:
Firmware versions on each KEF unit, the logs show LS50 II on 4.1.191 and the soundbar on 1.4.135; useful to pass to KEF.
As an interim test, try the KEFs over AirPlay/Chromecast instead of RoonReady and see whether those hold up.
Our working theory is a genuine KEF RoonReady weakness that your recent network change has made a lot worse. If we can pin down what happened on the 21st, we can separate the two. 👍
Thanks - yes i have sent Kef the logs and they have all the info (firmware etc). They say they are working on a fix for RAAT dropouts.
on 21st i added VPN to the Deco connection as the wisdom of the ROON community suggested using VPN might solve issues. Clearly not
Easy to turn off and see if that reverts the problem. Wired backhaul only added yesterday. I didn’t think throughput / bandwidth was the issue. But i was desparate.
So, I disconnected the wired backhaul and all was fine.
To have enough ethernet sockets, adding the backhaul had required adding a switch between the synology Roon server and the Deco node. I took the switch out after discovering the wired backhaul was not required. And the audio system fell apart again.
So i added the switch back between Synology Roon server and Deco node. All fine again.
There is perhaps something weird going on between the bonded pair of ethernet connections to the synology disc-station and the Deco. Which the switch appears to solve.
Nice detective work! that’s a really useful find, and it fits the picture.
The clue is the bonded pair going into the Deco. Deco mesh nodes aren’t proper managed switches: their two Ethernet ports are essentially bridged together, and they don’t do LACP or spanning-tree the way a real switch does. When you run a Synology bond straight into a Deco, the way the bond distributes frames (and duplicates broadcast/multicast) can confuse the Deco’s bridging, and RAAT discovery leans heavily on multicast/mDNS, so that’s exactly the layer that falls over. Dropping a plain switch in between gives the traffic a device that actually learns MAC addresses and handles the multicast cleanly, which is why everything settles the moment the switch is back in the path.
One thing that would help confirm it: on the Synology, what bond mode is set under Control Panel → Network → Network Interface? If it’s Adaptive Load Balancing or Balance-XOR, that would explain the behaviour perfectly. If you don’t specifically need the aggregated throughput, it’s also worth trying a single NIC into the switch, often simpler and just as stable.
Either way, keep the switch, it’s doing real work here, not just adding ports. Glad you’ve got stable playback back (and the Ethernet cables gone again ).
).