I’m trying Roon out, currently running the server on a QNAP NAS, but will likely move it to a different linux machine if I decide to subscribe and continue using it. I’m trying to connect via a Roon App running on a MacBook and presumably due to a more complex networking configuration where the Roon Server is not on the same subnet (e.g. App is on 192.168.6.0/24, Server on 192.168.1.0/24), it is not finding the Roon Server. The Roon App interface is very simplified and I don’t see a way to just specify the IP address of the Roon Server to the App.
Later, the server will be exposed to the internet, in which case everything might start working, but for now I just wanted to try things out on the LAN, which should work if I can point the App to the right IP.
Full disclosure - these different subnets exist because I have multiple site-to-site VPNs going between different homes and workplaces I am located in. This has worked seamlessly for many years with all sorts of applications and services - this is the first time I have encountered an issue where I can’t specify the address of a server to an application. I get automatically searching the subnet for user first-run convenience, but there should be an option to specify this.
TL;DR: Roon uses bi-directional multicast & broadcast for discovery of endpoints (server and clients) and without something like udp-proxy-2020 those packets won’t be forwarded between VLAN’s or over a VPN tunnel.
This is also why Roon doesn’t work over the internet. The Roon ARC client uses a totally different protocol/discovery mechanism and there’s no way for the normal Roon client to use that protocol.
@Colby_Boles, @Mark_Sealey’s suggestion is something needed on Sequioa systems after they have started or rebooted. You need to toggle the Roon setting from On to Off to On again, it’s a known issue with Sequoia that Roon is investigating. Once toggled back to On, Roon works normally. The other suggestions here also may be necessary based on your network configuration.
It does, by means of port forwarding, not by exposing the device as a whole to the internet. This will make ARC work, which does playback to that specific mobile device only. If that’s what you’re after, then that might be sufficient.
If you want Roon to discover endpoints other than your mobile phone, e.g. a RoonReady DAC or a desktop client, you won’t be able to use ARC. If those endpoints are on a different subnet, then server and client(s) won’t be able to see eachother.
Aaron has given some pointers as to how you can make that setup work.
Thanks. Now that you mention that this is using UDP, I get it. An unfortunate design choice IMHO. Looks like they went for maximum user convenience over setup flexibility. Do you happen to know if it attempts UDP-based discovery every time the app starts, or only to find the server initially? If the latter I may be able to setup a temporary server within the subnet and then find where the app is storing the server address (likely a plist).
I’m using a variety of Ubiquiti EdgeRouters, and there are UDP proxy solutions for those (e.g. GitHub - britannic/ubnt-bcast-relay: UDP Packet Broadcast Relay, integrated with EdgeOS CLI), but a couple of my routers are the fancier Ubiquiti ER-8-XG EdgeRouter Infinity models with 16-core processors, so I’m not sure if the aforementioned code can run on those (the code is older and already had to be split into two versions for some different EdgeRouter model predecessors with different processors).
In any case, I have a few things to try now that I understand how it works - thanks.
That was never the plan - I assumed it just needed a single port forwarded, which turns out to be the case. It looks like you can even pick which port it is using on the server-side, since you need to keep it at the same number on the WAN. I presume this is so that your ARC phone app can work both outside the home and when on the LAN at home.
I’m basing this on what I read here:
In the ARC case you are allowed to configure things manually, which is nice.
ARC is used for people who want to listen to music on their phone while out and about, while still having access to their library at home. Are you saying you only play back music on your phone?
@Colby_Boles You might want to clarify what it is exactly you are trying to accomplish and why, instead of focussing on how to do it (that would come later).
Every time it starts and it sends keep alive checks pretty often. It randomises ports its connects on over quite a wide range. I use Tailscale to connect to my server and not use port forwarding for ARC. This allows me to connect to my server but more often it won’t be visible as an endpoint. But occasionally it does show up if Roon has been left running on the laptop. It may not stick as it often drops off when laptop goes to sleep for any period of time and it won’t return. Same happens with my phone remote as well. But 99% it won’t ever work and that’s when you want it to.
One thing to take into account, even if you get it to work, RAAT, Roons streaming code isn’t designed to work over high latency environments which this will be and can really struggle to maintain decent playback. Roon has very strict requirements for latency to allow sync playback and you can’t override this. ARC there remote playback app was designed to work over the internet and has different buffering in place to deal with latency and doesn’t have the requirement for tight sync.
I don’t know how it works in detail. In addition, normal udp proxy/forwarder provided by OPNsense doesn’t work. I have to manually install the special version mentioned in the threads.
Gosh no. I was just saying that it was never the plan to expose all ports of a server to the internet, but I assumed at least one would be, unless ARC was accomplished through some proxy hosted by Roon, which doesn’t seem to be the case.
The goal is to have Roon playable in 4 different home / work locations as well as on mobile devices (iPhone+CarPlay, iPad+headphones) for 3 different individuals.