Dear Steve - I have similar, but not the same, problems with Roon ARC. Like you, I mainly try to use ARC whilst driving. On nearly all occasions I have to stop to log in to my Roon account. The access to the Roon Core seems very flaky and it seems to make a real mess of my playlists, often duplicating tracks. I end up just using TIDAL native over the WAN. It’ll probably all be fixed in the next release - isn’t that the usual mantra?
I was away for 2 weeks and ARC worked for about 7 of those days, was great while working. It seems problems are exacerbated if I move from one network to another. Was working on the hotel room wifi, went out with mobile network and it stopped working, came back to hotel, still not working and did not again until I got home and restarted Roon Server.
I was in the process of logging my recent issue with Arc which would initially connect fine but if I paused the app for instance and left my car it wouldn’t reconnect until I was back home on wifi. Anyway my recent experience with this issue was yesterday but when I looked at Settings in my Roon core (Mac mini M1) and then Arc it was showing a connection error stating the port nominated for Arc was already in use and it suggested I change to another port number, which I did and so far…all seems to be working fine. Have been using Arc today and it successfully restarts following a pause or closing the app.
Watch out now, offline doesn’t work as well. I have issues with mine. I had to reset and download files again. Luckily I have a streaming service I use too.
It works for me ok. But there is a bug that if the app has been updated and not recently synced it seems to not allow offline playback until you establish a sync again which is a bug. I had this moving from one version to another. After it had established a sync it was fine though didn’t have to reset or delete files.
After my short experience Roon ARC runs very well. Will give you feedback if meet any difficulty with
It seems that your problem is not in Roon at all. In order for Roon Arc to work stable you need to check following things: 1) Static real IP from your ISP, 2) working UPNP or manual port forwarding on your home network router, 3) static IP for your Roon Core in your home network. You also should check your settings under Settings - Roon Arc. Also you can follow the link “More info” under “Listening port” where you can find overview and troubleshooting sections of the Roon knowledge base.
To be precise, it must be a real, public, routable IPv4 address, but it does not have to be static; dynamic works and Roonlabs servers seem to figure it out if it changes.
2 Likes
After countless hours with the forum and almost non-existent tech support I have given up. Tech support’s final answer was for me to call AT&T because it must surely be their problem. I will stay with Plex Amp. It works remotely and I have lifetime access. Roon should hire their tech support.
1 Like
Last I saw it figures it out every 4 hours.
Tried out? That’s not great. In some other discussion that I can’t find anymore, I read a post from Roon describing how the authentication and the whole traffic flow works and it seemed to me that it can figure it out more quickly. (After all DynDNS services can as well).
Edit: The core can maintain an outbound connection to the Roon servers and will surely send a unique token, so I don’t see why the servers can’t know the current external IP of that token owner and tell it to the ARC remote
I’ve not read or verified anything different but…
My understanding is Roon, unless you set to port 0, will run its verification in the background every 4 hours. If it detects an IP change as part of that verification it updates. But it’s not testing any faster than that unless you click on the ARC tab in settings to force it. I know it is not nearly as aggressive as something like DynDNS.
It can but this wouldn’t be good service / resource management. It should be connecting to the cloud “on-demand”. This makes sure there is a constant rotation of endpoints against demand. Additionally, a socket with no traffic, has plenty of timeout obstacles to overcome from NAT, possible VPN, state full firewalls, etc. Using a watchdog or keep-alive to maintain such socket is a tad wasteful all-around. Roon Core services have no reason to know my public IP. Only ARC.
Yeah I don’t know, I wish I could find that post. However, I believe the forum would be lit up like a Christmas tree if people went through all the hassle to get their IPs working for ARC just to have it fail for hours all the time.
And I don’t think it’s makes a difference which parts of Roon know the IP.
I have no experience though as mine is static.
I found this which admittedly is not detailed and not the one I meant:
I hope that would have been qualified with “except for 4 hours if the ISP changes your IP”. And I find loads of user posts saying their dynamic works fine, and just a few where it didn’t, and those that I find are inconclusive. OK, many ISPs assign dynamic ones that however rarely change, if ever, but still I’d expect more uproar if it was a general problem.
You set up port forwarding manually on your router for other apps, but for Roon it doesn’t work? That does not make sense. Roon listens on a specific port, just like the other apps you use. You can test whether it’s open or not by going to a port check website. If it’s open, then the problem you have isn’t related to port forwarding.
1 Like
The state of resi Internet means the IP address rarely changes even if dynamic. You’ve got an always on device that must maintain a bunch of sockets for a bunch of at home automation stuff (echo, hey google, siri, your air purifier, thermostat, etc.) All those would reset if the address changes so, once you power on your modem / router, that IP generally sticks. This is why no one is complaining. Where is isn’t so true is with CGNAT which ARC doesn’t work with anyway. The public facing address on your router is a lot stickier than people believe. This is why people still use VPNs and Apple’s new “limit ip address tracking” feature at home.
Possible, I added this already to my previous post while you wrote. But then the end result is still that it’s not a problem
1 Like
I know this discussion has been going on for a few days and taken a few different directions but I feel compelled to weigh in. ARC sucks. It’s a huge disappointment and doesn’t work well (or at all) for me in offline mode.
The reality is that if Roon software was properly designed there would be no need for ARC. The functionality of ARC should exist in Roon itself. Having to learn another application is a pain. Especially when it doesn’t work. My 2 cents…
1 Like
Agreed.
Since Roon is the core of my home listening system, I was really hoping that ARC would result in a “one-stop” solution for all my listening needs. Sadly it’s just not ready for prime time (yet).
The networking set-up—which I never planned to use, but had to undertake just to use the app—was an ordeal.
Once I was past that hurdle it’s performance in offline mode has been flaky at best. Music I’ve downloaded appears and disappears unpredictably. Resetting the app sometimes temporarily fixes the problem but requires re-downloading all my music again.
Other apps such as Plex or EverPlay deliver Hi-res music without all ARC’s problems and work with Car Play.
When they get all the bugs sorted out I’m looking forward to using ARC. Until then I’m tired of being a beta-tester.
3 Likes
Well well well, as the originator of this topic, it is nice to know I am not alone on this one. I guess there is some work to do at Roonlabs Headquarters on this one. Thanks for all the responses.
4 Likes