Roon and my Sonos speakers were getting along well for months and months, now suddenly, without any network changes on my end that I’m aware of, having issues like “Tidal failed to login” that appears to resolve itself but keeps coming up. Music starts, then starts skipping like data transfer issues, then also sometimes it stops. The Roon client on mobile or desktop comes up, then suddenly says “waiting for roon server” then reconnects again. It is unuseable at this point. Where to begin to troubleshoot? If using Sonos S2 app with the sonos speakers, there’s no problems, steady and responsive app/volume control/etc.
I’m running Roon Server on a linux machine (ethernet connection) that has been solid for a long time. I’ve re-booted it a number of times. The linux desktop is not used for anything else and runs Linux Mint. My library is 6753 albums.
Network Gear:
MikroTik RB4011 router and access points by MikroTik Audience (2x) and cAP ac, all with wired backhaul configured centrally via CAPsMAN.
Thanks for the detailed description — based on your setup (RB4011 with CAPsMAN-managed Audience and cAP ac APs) and the symptoms you described (“TIDAL failed to login”, skipping playback, and “waiting for Roon Server” messages), this strongly points to multicast (mDNS) flooding across your network which is confirming by your logs.
Roon relies heavily on multicast (Bonjour/mDNS) for device discovery, and CAPsMAN setups often replicate this traffic across all access points and bridges. When this happens, Roon Core gets overwhelmed by duplicate mDNS packets, which can lead to exactly the issues you’re seeing — slow responses, unstable connections, and playback interruptions.
To resolve this, there are two recommended options:
Enable IGMP Snooping on router
This allows your switches and MikroTik bridge to forward multicast traffic only to devices that actually need it, instead of flooding the entire network.
Option 2: Use a Separate VLAN for Roon Core and a Few Endpoints
If IGMP snooping doesn’t fully solve it, the best next step is to isolate Roon Core and a couple of endpoints into their own VLAN.
This keeps mDNS and RAAT traffic local and prevents broadcast storms from other devices (Sonos, Apple TV, Chromecast, etc.) managed by CAPsMAN.
These two adjustments usually eliminate intermittent connectivity and TIDAL playback issues in networks like yours.
Start with IGMP Snooping first — it’s the easiest fix — and if the issue persists, try the VLAN approach.
Thanks for that quick reply. I enabled IGMP Snooping. Rebooted Roon Server and one of the endpoints. Definite improvement right away. But, am now seeing different error resulting in lost play, namely “Lost Control of Endpoint”. Happened twice, I’ve restarted playing a few times, and now hasn’t come up again yet, will monitor.
Is it advisable for myself to review logs and attempt to learn and spot issues? I’m guessing you don’t want to officially advise people to be digging into logs - but if Roon’s position is otherwise, I’d love to know more about what to look for.
Lastly, I am investigating reconfiguring my network with VLAN. You mentioned Roon Core and a “few endpoints”. Any further detail on endpoints to include or not, or potential downsides? AI says: perhaps to add per-VLAN filtering, isolating Roon Core + key endpoints (Roon Bridge, etc.),while still allowing discovery across VLANs using mDNS reflector.
You don’t have to check logs, important issues and errors are automatically reported to Roon and we can sometimes if you have errors.
Yes, if IGMP snooping causes the devices fall backs you might try to put your Roon Core to the separate VLAN in order to isolate it from the multicast traffic caused by large number of other devices Just put some of your endpoints (whatever you like) to the same VLAN and keep it like this for some time and observe whether your playback is more stable.
P.S. you don’t have to enable mDNS reflector. With this test we’re trying to isolate your Roon Core and audio devices from the tons of multicast calls coming from other devices.
Let us know please if you have questions on making the isolated VLAN with your Roon ecosystem.
It’s much more stable now. I’ve used AI to tweak the CAPsMAN, methodically dialing in the router and 3 APs - I can share that AI was very helpful, but I had to babysit it really closely, but after three days of chatting had made many improvements that I already notice. The mikrotik system was too complex for me to fully understand and tweak, but with AI, I feel it was possible to navigate through.
So far so good, hopefully days ahead will bring more of the same. I do plan on upgrading my RouterOS to v 7.x, which has some key improvements and try not to break what I have now (but backed up of course in case of needing a rollback).
We’re glad to hear the setup has stabilized. Two important notes to keep in mind as you build components back into the network:
Roon devices must all sit within one VLAN (device discovery traffic won’t cross VLANs reliably)
Multicast traffic must be allowed to flow freely within the VLAN. Aggressive packet scheduling or other network management techniques can occasionally alter the order of packets in a way that Roon does not anticipate, even if overall throughput remains sufficient.
We’re happy to help out if you hit any snags. Please see our best practices here for a more thorough overview:
Thanks for the help. Update I have upgraded RouterOS to 7.15.3. I will not be segregating Roon into it’s own VLAN as I don’t feel it’s necessary and that comes with some downsides. Currently very stable, and in fact I can add more speakers and control them all easily, whereas in past more than 3 sonos at a time was challenging and with every song change it took a bit for all speakers to play. For reference and perhaps to help others, here are main changes made (note I have an old house with brick exterior walls, lathe and plaster walls and covering basement and two floors plus attic that has bedroom, bath and TV space, so it is a challenging house for wifi).
DHCP stability:
/ip dhcp-server set [find name=“home-network”] lease-time=12h
→ Prevents short leases and discovery loss.
Wireless tuning (Sonos/Roon stability):
/caps-man configuration
set cfg24, cfg24guest, cfg24-6, cfg24-11 channel.band=2ghz-b \ channel.control-channel-width=20mhz channel.extension-channel=disabled
→ Forces 20 MHz width, ideal for 2.4 GHz in dense structures.
TX Power optimization:
2.4 GHz radios = 14 dBm
5 GHz radios = 18 dBm
→ Reduces interference and overlapping AP power overlap.
Static IP assignments:
/ip dhcp-server lease
all SONOS speakers that are hardwired (3 out of 8) were given static IP addresses.
CAPsMAN datapath confirmed and corrected:
/caps-man datapath
set [find name=“datapath-SSID”] local-forwarding-interfaces=bridge
set [find name=“datapath-guestSSID”] local-forwarding-interfaces=bridge
→ Ensures traffic stays local, improving multicast and latency.
From here will monitor, possibly tweaking transmission/radio power by +/- 2 dBm increments, setting RSSI thresholds if signal overlap is excessive, I will be adding in a managed switch (replacing an unmanaged switch for more ports, future proofing, that support IMGP snooping and VLAN support (will be putting IoT devices on a separate VLAN that should cut down the noise).