It becomes very difficult to use ARC, it constantly indicates weak connection problems, even with 5g and good coverage, cuts, etc. while the rest of the applications (Tidal, Qobuz) reproduce at maximum quality without problems. It’s a shame, the effort is appreciated but it hasn’t improved at all since the launch. If we add that in Roon we cannot add songs to the Tidal lists, it forces you to do double work if you discover a song on Tidal, then having to add it to the Roon lists for the second time in Roon. Let’s hope that its operation improves, I would prioritize stability with the connection before adding new functions. Greetings.
I’d be happy to give ARC a try when it works with starlink and I don’t have to hack my system. Wish I could have the 4 hours back that I spent trying to get it to work when ARC first came out. Would have been nice had they mentioned the limitations at that point…
It’s a really weak solution. Just let us use the real, Roon client, wherever we are, on whatever device we want. Not just a phone.
If I could install a real Roon, at a second home, or at work, or on any device, anywhere, that sourced my collection from my home, that would be great.
Why is it so complicated?
1 Like
It really is. The real seamless solution is as you say - the regular Roon mobile client working remotely via VPN or through the mechanisms ARC works through.
I would love to remotely use Roon on my laptop. I even have a home VPN setup but to even have that work with Roon requires a significant effort of setting up UDP forwarding through specific ports and is something I haven’t quite gotten to work. Nearly everything else I use via VPN transparently works.
The fact this isn’t the case screams “tech debt” to me with the Roon remote apps for desktop and mobile. It was easier for them to build a brand new app than to refactor the existing infrastructure to support a clearly common need. My guess is to allow users to access their music remotely on a non-mobile platform like a laptop, they’d need to introduce “Roon ARC Desktop”, which is just ridiculous. Though, as a lifetime member, I’d vote for functionality first and optimal design second and be happy to see at least a step forward, as long as there was acknowledgement that the ideal endgame here is a single app per platform that does all the things!!
1 Like
Because RAAT is designed for high-bandwidth, low-latency networks like home LANs. See the posts by people who even have issues on not-so-good wifi. And now you want to use it over 4G networks or across the internet. And this high-bandwidth, low-latency expectation may well permeate much of the code of the regular remote app.
In addition to the bandwidth and latency issues discussed by @Suedkiez, either or both of Roons discovery of endpoints by the server and/or the server(s) by the endpoints relies upon broadcast packets which are constrained to the local network. If Roon did not rely upon such broadcast packets for discovery, then the act of configuring new Roon clients would not be “plug and play” as it is designed to be.
To get around this and allow Roon to function across sites would require that both sites were part of the same LAN. This is possible using a VPN to bridge both networks but I don’t think doing it is within the capabilities of many who have no interest in networking technology and only want to use networking to achieve, say, audio distribution. It would also require particular networking products that are not universally available. For example, My router can act as a VPN server or a VPN client - so I could use such a router on each site to create such a VPN - but this capability is not typical of the routers supplied by ISP’s.
Even if Roon did not rely on mechanisms that are inherently limited to the local network and even supposing the bandwidth and latency were not an issue, making it work across sites without the use of a VPN, would likely involve configuring the router to forward ports for both the Roon Server and for the endpoints (at least those that were on a different physical LAN to the server). As well as increasing the vulnerabilities due to open ports (significantly beyond those required for ARC), this would also represent a configuration complication that may not sit well with many/most of Roon’s users.
Note: there are various mechanisms which could be used that would render the above paragraph incorrect but they would almost certainly have their own serious implications - some of which may be unacceptable to a significant number of Roon users.
1 Like
Another possibility for addressing inter-site Roon use which I had thought about, and which may be more tenable is to use the ARC connection technology to create a Roon Proxy Server (a device that looks like a Roon Server on the local network - but actually works as a gateway to the actual Roon Server on the remote network. Such a device would use a ‘fast download’ to get queued tracks from the Roon server (not using RAAT) , buffer the stream(s) sufficiently to mitigate internet delivery latencies and then forward stream(s) to the relevant endpoint using RAAT/Airplay/Chromcast/whatever.
The user could then configure the Roon Server at their primary site and a Roon Proxy at a secondary site.
Remotes connecting to the Roon Server would only see the endpoints at the primary site.
Remotes connecting to the Roon Proxy would only see the endpoints at the secondary site.
Edit: Feature suggestion topic added at: Roon Server Proxy Device for access to Roon from a second site
2 Likes
No use to me at all - I simply download to Qobuz app and listen if I am away
1 Like
If your are referring to my ‘proxy’ suggestion, I can’t say it would be much use to me either. I don’t even use ARC very much - for the same reason - except sometimes in the car - but even then I find a library subset on a USB stick connected to the car media player is usually more reliable.
But it may be of use to those that run two or more homes and want Roon in both (as an alternative to the ‘ARC on Desktop’ suggestion in the feedback/suggestions area. It would be a more flexible solution to ARC on Desktop.
No just ARC in general…
I have used sonicwalls to setup site to site VPN and they work great (business and home). But, that is a lot of hassle and expense most users do not want to have. Roon certainly doesn’t want to have all the extra support extended networks would create.
1 Like
Not interested - It’s more like a gadget for me. When I travel I can use Qobuz direct - no need to have access from outside - and still not sure about risks.
1 Like
So 20% users of Roon have no particular interest in using ARC currently, so it’s clear that the concept of ARC is very popular with 80% Roon users with 20% having trouble getting it to work.
I think we can pronounce ARC a qualified success for Roon users.
Errrr…
Well, on a personal level, being in the 20% that would love it if only it worked, it does not feel like a success. On a more objective basis, if 20% of your user base can’t make a new feature work, it’s not great.
I’m not really complaining mind you, it wasn’t on the roadmap and I can live without ARC, there are easier ways to have my music travel with me. I haven’t even contacted support to try to sort it out. But could we say that while the concept if a big success, the actual implementation is lacking?
3 Likes
I have previously been a bit of a die-hard about only relying on locally-stored music - even though the quality of the metadata in my files, which have been accumulated and ripped over a couple of decades in a wildly inconsistent fashion, can be quite variable. Anyway, I recently upgraded to an unlimited data plan, and was quite looking forward to using Roon ARC, particularly through Android Auto. Instead I’m using Plexamp in my car. A lot.
Plexamp seems to be a lot more reliable. Some of the freezes on ARC might be connection based, but a lot seem to be just software-based. Anyway Plexamp has none of these issues. I seems to down-rez to Opus 128 at the first sign of trouble, which doesn’t bother me too much in my extremely noisy vehicle. It pulls just enough metadata (album art mostly) to look fine on an android auto screen.
But what’s really surprised me is how Plexamp does quite well what I would call, low-power discovery, and makes it reasonably accessible from the Android Auto UI. ARC basically offers you a browse of recently added or played albums, its daily mixes or search. As well as Roon Radio based on the last artist played (which seems to end up on Baba O’Relly regardless of what pre-1980 music I had playing). Plexamp offers you a series of slightly gimmicky but generally solid genre-based or mood-based radio stations, or just lets you play within artists you own (I generally see Plexamp’s poor Tidal integration as a feature rather than a bug though I am sure lots of users would disagree).
I maintain two roughly similar libraries, one for each of Plex and Roon, which is a chore. But absent a bit of a bump to Roon’s reliability (or an easier way to swap connection reliability for sound quality) it’s probably Roon in the house, Plex on the road.
Just back from a week in Allgäu 
Used ARC in the car and with my FiiO KA17 and iPhone 15 Pro. Worked just fine all the time - cellular and WIFI (Airbnb)
Torben
1 Like
I would use Arc if it worked on my ISP.
I used it up until a few days ago, now it doesn’t work. From reading Support threads, It seems Roon made changes in March - April 2024 which broke ARC for people on IPv6 and in trying to fix that, broke ARC in mid April for people stuck on IPv4. There’s an unhelpful suggestion that we contact our ISP for special treatment around CG-NAT. Ha! Try getting ANY service from Comcast (US)!
1 Like
Back on ARC! Roon support figured out my expired NordVPN subscription was routing my traffic in the background (Nordlynx?). A reminder to monitor certificates and fully remove apps that aren’t being used.
I enjoy using ARC when away from my network. I use it every time I’m in my 4Runner via Apple CarPlay as well.