Roon finds the same audio devices multiple times because of different network interfaces? I am currently evaluating the roon trial, but one problem is completely keeping me from using it. When i start roon on my windows machine it adds all the output devices multiple times. When checking the raatserver logs i can see the following sections: ``` 10/27 15:00:08 Info: [discovery] [iface:Tailscale:100.77.56.51] multicast recv socket is bound to 0.0.0.0:9003 10/27 15:00:08 Info: [discovery] [iface:Tailscale:100.77.56.51] multicast send socket is bound to 0.0.0.0:63352 10/27 15:00:08 Info: [discovery] [iface:Ethernet:192.168.178.205] multicast recv socket is bound to 0.0.0.0:9003 10/27 15:00:08 Info: [discovery] [iface:Ethernet:192.168.178.205] multicast send socket is bound to 0.0.0.0:63353 10/27 15:00:08 Info: [discovery] [iface:Ethernet 4:192.168.56.1] multicast recv socket is bound to 0.0.0.0:9003 10/27 15:00:08 Info: [discovery] [iface:Ethernet 4:192.168.56.1] multicast send socket is bound to 0.0.0.0:63354 10/27 15:00:08 Info: [discovery] [iface:Loopback Pseudo-Interface 1:127.0.0.1] multicast recv socket is bound to 0.0.0.0:9003 10/27 15:00:08 Info: [discovery] [iface:Loopback Pseudo-Interface 1:127.0.0.1] multicast send socket is bound to 0.0.0.0:63355 10/27 15:00:08 Info: [discovery] [iface:vEthernet (Default Switch):172.18.224.1] multicast recv socket is bound to 0.0.0.0:9003 10/27 15:00:08 Info: [discovery] [iface:vEthernet (Default Switch):172.18.224.1] multicast send socket is bound to 0.0.0.0:63356 10/27 15:00:08 Info: [discovery] [iface:vEthernet (WSL (Hyper-V firewall)):172.18.0.1] multicast recv socket is bound to 0.0.0.0:9003 10/27 15:00:08 Info: [discovery] [iface:vEthernet (WSL (Hyper-V firewall)):172.18.0.1] multicast send socket is bound to 0.0.0.0:63357 ``` and: ``` 10/27 15:00:14 Trace: [ipaddresses] enumerating addresses 10/27 15:00:14 Trace: [ipaddresses] FOUND Tailscale 100.77.56.51 10/27 15:00:14 Trace: [ipaddresses] FOUND Ethernet 192.168.178.205 10/27 15:00:14 Trace: [ipaddresses] FOUND Ethernet 4 192.168.56.1 10/27 15:00:14 Trace: [ipaddresses] SKIPPED ZeroTier One [25e3d94718464960]: not up 10/27 15:00:14 Trace: [ipaddresses] SKIPPED Bluetooth Network Connection 2: not up 10/27 15:00:14 Trace: [ipaddresses] FOUND Loopback Pseudo-Interface 1 127.0.0.1 10/27 15:00:14 Trace: [ipaddresses] FOUND vEthernet (Default Switch) 172.18.224.1 10/27 15:00:14 Trace: [ipaddresses] FOUND vEthernet (WSL (Hyper-V firewall)) 172.18.0.1 ``` It seems that it is searching for the audio devices on multiple interfaces, instead of just the local ethernet. This is confirmed when i check on the roonremote mobile app as seen here: https://i.imgur.com/grtOWkU.png As you can see each device appears multiple times, on different ip's.
Describe your network setup
Roon Server running on a local linux server. Windows laptop running the regular roon windows version. Both are connected using tailscale.
The Linux server running roon has a ton of other services occupying the ports, which is why I have roon running in a docker container which is connected as a tailscale device. This is completely unrelated to the problem though, as the problem persists if I run the server on a regular local server without tailscale. The server itself works perfect. This is only related to the windows client.
And there is no Tailscale on the client? Be aware that device discovery, including local ones, goes through the network layer.
As far as official support goes BTW, you probably have to replicate the issue without any VPN involvement (if it still occurs) as VPNs are not a supported configuration. (Except ARC with Tailscale)
sorry for not adding that in the main post. yes tailscale is of course also installed on the clients. the setup is identical to the one described in the arc with tailscale post so i do not see how this is not supported. however i wanna emphasize again, that the issue persists with zero involvement from tailscale (or any other vpn). the problem is that raatserver seems to search on all network interfaces on my windows machine. since i also have other things installed there, mainly wsl (because i use it for coding), it seems to search those as well. the tailscale network interface in this case also causes doubling, but so do any other interfaces there. again, this is completely seperate from the setup on my server. this would happen with any other setup from what i can tell, when you have wsl or tailscale installed on the windows client.
This must be a Windows-specific issue. I have three separate Roon server setups, two with Roon server on Ubuntu Server, one on macOS. All the machines involved run Tailscale, as well as my macOS, iOS, and Android remotes.
I also found this previous issue from a year ago (here), that seems to mention the same problem. It seems it was closed with no efforts to solve it? If i understand correctly, roon staff simply says that you cannot use the client on devices which have other network interfaces installed? this would make roon completely unuasable on two of my main listening devices. if this is the case i will definetely have to cancel my trial which i really don’t wanna do as i love the app when it works. From what i understand they don’t wanna add a gui friendly option to select a preferred network interface. I would honestly be perfectly happy with some way to block the interfaces through some config file (the bits file in the raatserver seems to do something similar), or block them in some way through the firewall. however after mutliple hours of trying today, even with wireshark, i could not get it solved myself.
Yes this is definetely windows specific. The issue directly stems from the interaction between the RAATServer.exe and how it discovers audio devices through all network interfaces on windows. Unfortunately I have two windows devices that I use to listen to music so i cannot use another os all the time.
VMs and Docker itself have nothing to do with the problem. It’s just that docker desktop on windows for example creates a new network interface since it runs through wsl. Simply having docker desktop installed, without ever having it interact with roon or even using it, will already cause the problem. And i find it hard to believe that the answer to this problem is to simply not have things like docker or a vpn installed on the system. I only want to listen to music while working without having to carry a dedicated streaming client around with me all the time.
Well, WSL is a VM of sorts and it creates a virtual network adapter. From the link you posted (and @BlackJack is one of the most knowledgeable users on the forum):
Other than that, official support will have the last word.
Why don’t you try and do that then? You need/have entries already for the parts of Roon, so go on and restrict them. From the thread you linked:
Keep in mind that Roon also needs internet access too (don’t sever it in the process) and check the routing table too.
But as already stated, Roon Labs designed Roon (the product family) for simple (flat) home network environments as typically provided by default from ISPs and their hardware. It is not designed for complex network environments with VLANs and multiple physical or virtual network adapters. So there is (still) no official support for operating Roon in a complex network environment. You may find inspiration and community support in the Tinkering section on the forum but without the promise of a solution for your case.
That is exactly what i tried yesterday for around 5 hours. I probably tried around 100 different firewall rules, roon always still finds either all devices or none. I first tried putting the scope of the allow rule only on the tailscale range for both roon.exe and raatserver.exe; it still found the devices under docker. Then I tried adding a specific rule that blocks all traffic on all protocols and all ports in the 172.x.x.x subrange that docker desktop uses. Roon still finds & shows all the devices in the 172.x.x.x subrange after that. I don’t know how this is possible and what magic the raatserver is using to still find the devices, but it is.
I don’t know why that worked for you, but it simply doesn’t on my end.
Roon will always find the interfaces themself, that can obviously not be blocked by firewall rules. You can only block Roon’s communication over certain interfaces - so Roon should ignore them. It probably worked for me because I use different directly attached networks (VLANS) only and not a VPN (and Docker, and …).
Note: The VPN can provide a tunnel, the tunnel endpoint address (of the tunnel adapter) can be completely independent of the network that gets tunneled trough the VPN. If you tunnel your local network, things might get ugly quickly if you don’t pay attention (circular connections, multiple routes with the same priority, …). Additionally is device detection (for Roon) based on multicast protocols (a different address space than your normal network) which usually poses no issue in simple, flat networks as required by Roon but can create an additional challenge on complex network setups.
From your statements, it seems you want to use a Tailscale VPN tunnel (in your local network internally?) for some reason. As others already posted, this is not officially supported (with the exception of ARC that already has been pointed out) because there seem to be to many ways to “shoot yourself in the foot”. So this seems to me to be the wrong forum category. You may find inspiration, instructions and help in the Tinkering category.
PS: Roon may just be the wrong product for you. You may only be able to use it successfully if you are able to (re)create a simple, flat network like environment as required using all the complex tools (virtual and real machines and networks) available to you, heck you may even have to add additional hardware to make it work (adding a dedicated Roon Controller and Endpoint Windows PC that is connected to the one relevant network only for example). I don’t know if you are able/willing to go this extra mile to make Roon work in your environment or if it is even worth to try. You can create or add to an existing Feature Suggestions as suggested by Roon Labs staff in the thread you linked, but this will not change fundamental parts of how Roon works in the near future – so this is hardly an alternative if you want to use Roon from now on.
AceRimmer
(Smoke me a kipper, I'll be back for breakfast!)
18
Moved out of support as it is not a Roon support issue at hand per se.