My Mac has two IP addresses: one is provided by the local network, the other by tailscale. Roon selects the local network IP address, so I’m not able to use Arc to connect to it.
Tailscale provides a network interface and IP address that shows up in ifconfig, so there’s no reason Roon shouldn’t be able to work over it.
How can I configure Roon to listen on the correct IP address?
I am not going to open a port on my router - there’s no need to. I just need Roon to select the other IP address.
Not sure if it’s the same issue, but I’ve also got a problem with Roon using the wrong external IP address for access. My ISP (like many, I think) can provide a public IP address, but it is NOT the same external IP address assigned to my router for outbound access (as seen through trace routes). Presumably this is a security measure. There really should be a way to specify the external IP address for the Roon setup.
It’s the same basic issue, yeah: I should be able to 1) listen on any / all IPs and 2) point Arc at a specific IP.
I suspect they’re doing a lot of automated stuff to simplify things for people who are less comfortable with networking. Which is fine - but it should still be possible to manually set an IP and go.
You can change the priority in the network panel by dragging an interface up or down the list (perhaps needs the option key, can’t remember), perhaps this will influence Roon?
Thank you for reaching out and I appreciate your patience while waiting for a staff response.
Here’s where we stand:
Unfortunately, the ability to point ARC at a specific routable IP address is a feature that fell on the wrong side of the delicate balance between product flexibility (for network-savvy users) and UI simplicity (for the bulk of everyday users).
Including this feature is the obvious workaround for the predictable and admittedly maddening problem you’re encountering with your particular network. Including this feature would, with similar predictability, ensnare a massive percentage of our user base in an infuriating and easily avoidable obstacle to the automatic configuration of port forwarding by giving them more control than they need.
In other words, with ARC as it’s currently built, this feature might solve a problem for 6 people but could be a massive source of confusion/frustration for the other 999,994.
In general, Roon is going to use the path of least resistance to get to the outside world. If a user aims for Roon to use a specific external interface/IP then they need to configure their network such that the Core’s traffic is routed via that interface by default. It’s certainly possible that prioritization can influence Roon @mikeb suggested above, but the ability for ARC to designate an IP as you’re requesting remains a feature suggestion at this time, not a support issue.
If you’d like, we can merge your post into that section for other users to contribute. Remember, this is just the first iteration of ARC, so the team will be noting suggestions with enthusiasm.
Totally understand what you are trying to do here, however:
you could offer both options, easy setup (multicast discoverable) and advanced setup (point to IP, port configuration setup.
You could take the lead of what the wireless industry did (and spend their millions in user testing) with home router setup, which is arguably the the most complex device for the average home consumer. They offer quick fast setup, and more complex setups for specific or nuance.
Also as another bench mark of software complexity / setup. PLEX has a much larger , wider and complex audience than Roon. They figured this out for their video stream audience as well, and works just fine. Slightly different approach, but would be better as the server location is aware via account sign in. Which you already have us do, by signing in with an account!!
Both can exist side by side happily, and then you would have 100% of your assumptions around your product audience covered. You wold get a lot of steet cred for listening.
don’t assume that you have your audience understood, you could simply ask your roon audience if they would like this feature.
I would argue, you already have a specific technical audience. Most of us are likely audiophiles (this is not a 6 person problem) that also have storage networks, more complex home networking setups , advanced audio device and setups than the average listener.
discovery based setups in software, are often more complex to develop for as they have to account for so many situations vs more direct config setups. ie enter an ip address. They also have to account for so many use cases, and still fail.
For example in my setup… I have my roon server with storage in one location and want to play from anywhere in my network which is from 3 different home locations connected by multi-point Wireguard VPN. Wireguard does not support multicast therefore roon auto discover does not work.
However if I could just point to an IP address of my roon server then it works just fine. I know this setup works with Roon because for awhile prior to my VPN setup I had my client open which still had awareness of my Roon Core destination. And only stopped working until I open and closed my Roon app.
Please re-consider this position. I know you would make many more of your customers happy.
Roon built a fancy mechanism for setting a configuration string. For at least a subset of users, they got that string wrong, and provide no way for us to fix it.
I don’t expect Roon to make users enter IP addresses. The discoverable thing is cool, for the people who need it, and benefit from it. I don’t need it, and it hurts me.
You could have a radio button with one option “automatically discover IP”, and another “manually enter IP.” Or, if you really think that’s going to cause tons of support requests, you could let advanced users edit a configuration file, so it never appears in the UI.
It seems the complexity ship may have sailed a bit already. And I find it ironic (and insulting, to be frank), that one of your suggestions for users is to configure their Core/network with a static IP; but when I ask to configure the Core to bind to a particular IP, and to configure the client to connect to that IP, you dismiss me as being in 0.0006% of users. There are more than 50 forum threads that reference Tailscale alone, and does Roon have anywhere near a million users?
Anyway, I know 100% for a fact that Roon understands this from a technical standpoint. The fact that you are able to build this sort of discovery system in the first place is proof of that. If you believe there’s a business case for violating fundamental principles of networking… well, there’s nothing I can do about that.
Welcome to Community and thank you for laying out your case, and thank you @PatMaddox for a well-reasoned response.
It’s precisely to invite this lively discussion that we’d attempted to honeypot this post in the #feedback:feature-suggestions category. There your arguments will have a chance to win both traction and the eyes of senior leadership, as that subcategory sees far more sustained traffic than older support threads.
As I mentioned above, this is the initial implementation of ARC, meant to work most simply out-of-the-box for the widest swathe of our user base. We’re aware of the frustrating position you’re in, but you’ll find technical support’s ability to assist you is understandably restricted beyond the functionality of the recently-released product. Attempts to escalate your carefully articulated opinions will be most fruitful in another category. Please understand that tech support can communicate Roon’s stance but not negotiate it, so any sparring here is just needless attrition.
I’m also running into this issue, but in the context of trying to use Roon with Tailscale since I neither want to enable UPnP or open up ports in my firewall. All I need to do is specify an IP address somewhere (anywhere!) and everything would work. There’s a way to do this in the main Roon app if it can’t automatically find the core (albeit several clicks deep, and that’s fine), but the Roon ARC app has no such functionality.