Core Machine (Operating system/System info/Roon build number)
Roon Rock OS on Intel NUC8i7BEH (DHCP static IP) Rock Version 1.7 (build 571)
Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)
Stable Mesh WiFi network. 4x Asus Lyra in AP modes Switches Netgear Prosafe GS108E en GS105E, Default Gateway ASUS RT-AC3200 router (WiFi disabled)
Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)
Cambridge Audio 851N Wired Ethernet (DHCP static IP)
Description Of Issue
Problems connecting to ROCK with Roon remote on serveral cases. After some time problem disappears and a connection is made. (Only after forced ending the roon application and starting it again.) After connection it’s working flawlessly … All Android devices suffer from this. It looks like a windows client is not showing this behavior.
Has done this we will see… Sometimes it’s also not occuring. But when it does, it’s quite annoying. Forgot to mention default router is running tomato (latest version). Enabled Muticast forwarding under the “advanced -> routing” tab under “Miscellaneous” “Enabled Efficient Muticast forwarding” We’ll see if things have changed. Thanks for your effort and input.
When I had one of those switches between my core and my WiFi AP, I had to use its Web interface to turn off IGMP snooping, otherwise my Android devices would lose contact with the core as you describe. IGMP snooping tries to “optimize” IP multicast, which Roon uses, but that “optimization” does not play nice with Android remotes for some mysterious reason that Roon engineering have been unable to replicate in-house. They tried hard, I even gave them access to my own network to run packet traces, and it was never clear what was triggering the problem. Until I turned IGMP snooping off at the suggestion of another Roon user, and life was good.
I have IGMP-snooping only enabled for VLAN ID 4 (For IPTV) and not for default VLAN. Two switches that only have default VLAN configured have IGMP-snooping entirely disabled.
But problem looks more or less like the problem descriped recently by another user. Suggested workaround for android devices is to end te seach for the core at startup and to enter 255.255.255.255 in the field showed after pressing help. After that just press ‘scan’. It then will show the core-server. Very strange but for some reason it works. It’s quite strange because entering the ip-address or hostname (from local dns-server) does not work.
Enabling IGMP snooping makes it worse. One thing thats crossing my mind. Why is there no 2 way connection possibilty. 1. Just by IP / hostname and 2. Core Discovery by broadcast. The first is always the fastest and nicest. (If it only was for unwanted networktraffic) (And Option 1 also gives the opportunity to use Roon across different subnets.
But to be honest I had no problems today. But discovery sure takes a while on Android. Apple- and Windows devices are much faster at startup of Roon Remote.
But after a view times start and stop someone will certainly see a waiting to connect screen not coming any further.
That’s along the lines of what we have seen in reports as well. The issue here is that we have not managed to reproduce this behavior in the lab with our gear, though we are tracking the reports from the user-side as well.
We are tracking the reports and we do plan to take a look and see what Core discovery improvements can be made down the line, but unfortunately we cannot comment on when exactly this will happen.
I have been discussing these Android multicast reports with the team and it is something that we are looking to improve, but no timelines as of now.
Why not simply resolving by DNS hostname. For example “rock.domainname.local” “roon.domainname.local” That should work in almost any case. (presuming these dns entries do exist and DNS is functioning right) And if that doesn’t resolve anything than IGMP multicast. And if that also doesn’t end in something useful by prompting for an ip-address. Such an approach would speed-up startup and make it more reliable and useful.
Thanks for the feedback here @Bennard_van_Diermen. As I have mentioned, we do plan to allocate some time see what improvements can be made here with regard to multicast, but I cannot specify when this will reach the top of the development queue.
IP multicast discovery also works “in almost any case.” The challenge is to build something that will always work, for a ridiculously large space of possible hardware, software, and network layout. The zeroconf .local DNS setup that you are recommending has not worked well on mixed networks like mine.
Roon are well aware that Android and IP multicast have an uneasy relationship, but it’s hard for them to find a better alternative when they are unable to replicate the problem in their systems. I spent quite a bit of time helping them on this on one of my past home networks, the problem is really sneaky.
A solution using local DNS name-resolving is something that works for any type of host and any type of os. I can’t think of any situation where this should not work. Because of this it should be the first thing to rely on. And this also makes it possible to use roon across multiple subnets. I think this would surely make many lives much happier.
I don’t see any local DNS server on my LAN (routed by Ubiquiti EdgeOS, if you want to know). Sure, I could set one up on the router or one of several servers if I cared, but how is that a foolproof solution?
If DNS isn’t working almost nothing is. Relying on something so evident and critical is not a bad thing. Quite a lot of end-users will use local DNS for DNS caching/proxy. And exacly knowing where to connect to is certainly a more elegant way than shouting out for servers to ‘maybe’ connect to. But certainly we can agree to disagree…
Of course access to a public DNS server is pretty much universal. But that is totally different from running a local DNS server to provide .local -> local (NAT) IP address mappings. Some operating systems (macOS for sure, maybe others) have tried to provide a lightweight local name service via mDNS, but it does not work well in my long experience, and anyway relies on IP multicast which is the root cause of the issue under discussion (I’ve been running my own networks, and written actual networking code, for longer than DNS has existed, if you need to know). Setting up a local domain name service that works smoothly with global DNS on a heterogenous network is not for the timid, and definitely not something Roon could rely on.
I’ve it up and running. Simple and straightforward on an asus router. But many many other routerbrands.have this DNS/DHCP functionality by default build in. Very simple and very reliable… For example draytek bintec lancom asus linksys tp-link and cisco if you have the skills. But there will be more…
