On the Arc home screen, I now see both my cores listed. Now I can only access the active core, the other one is listed as “last seen X hours ago” (where X is where I arrived at my second home and activated the core here, and deauthorized my primary home core). Feels like it’s getting closer to the idea that I might be able to be link Arc to my primary core so that I don’t have to wipe all my downloads every time I move between cores. Just hoping / guessing.
For those who have this issue (multiple cores which you switch back and forth between, ARC forces you to reset losing all downloads when you unauthorize / authorize) I’ve found a way to work with it better. Unfortunately it’s not great, but it’s better than the alternative.
Normally I’m at Home A most of the time. So ARC is sync’ed with Core A.
When I go from Home A to Home B, I unauthorize Core A and Authorize Core B. When I start ARC and Core B is authorized, it says “can’t connect to your core, please reset”. Which I used to do and download (slowly) a bunch of content, every single time I went back and forth.
Now, instead I just don’t start ARC when I’m at Home B / have Core B authorized. When I get back to Home A and reauthorize Core A, I start up ARC and it’s none the wiser. Which means (a) I don’t have to download anything, but (b) a mobile app is unusable to me based on where I am. So it still sucks and is weird and has congestive overhead, but is kind of better than where I was before.
@brian i know you don’t comment on roadmap, but I was wondering if you have discussed the concept of multiple core synchronization or at least breaking the idea of ARC has to be synced to only an active core (so long as you have an active core)? This is increasingly painful. I could do a partial solve by buying another license for Home B / Core B, but I’d then have a bigger problem with remembering which one is the primary (old: “master”). I know ARC began to solve for truly secondary locations where you don’t have multi-zone/DSP etc, but it feels like “secondary but co-equal needs” is still an orphan. I’d really love a solution where you have a “secondary / remote” core which phones home to the primary core and keeps everything (except possibly music files, though that would be great if potentially rife for abuse) in sync, so long as you only have one playing at a time. Or I’d happily buy a second license (even if I were only going to use one at a time) if only it could keep all my data sync’ed.
Here’s the original thread from the archived 2.0 testing where I started to work through this:
https://community.roonlabs.com/t/make-arc-work-simply-with-multiple-cores/208926?u=johnny_ooooops
I bought a second Roon license for my account. Works a treat and I don’t even have a second home. Right now, my 99 1/2 year old mother-in-law’s home is almost our second home. We’re spending a lot of time with her.
I don’t know, but seems like you could set up Roon ARC on a second Roon core using the same license and a different iPhone or iPad. The second location would need a router that could do port forwarding. I could be wrong. Earlier, I was considering some sort of cellular hotspot that could do port forwarding for use at the MIL’s house.
We’ve been talking about “location sync” use cases for 15+ years.
There are a few problems with this idea, none of them related to the usefulness of the product to the people who want it:
- It is a very complex and costly feature to build
- It creates a “tax” on everything we do afterward, as everything needs to consider location sync.
- It is costly from a QA / support perspective because multi-location setups are complex to create and recreate when troubleshooting.
- It’s very easy for a developer working on just about anything to break location sync accidentally. Combined with the difficulty/cost of testing it, it’s likely that this feature would break more often than we’d like.
- Multi-location setups are an absolute nightmare to support because the user only has physical presence in one location at a time.
- The proportion of the user base that has multiple homes is very small. Our most liberal estimates are around a few percent, but the number of people who would actually set up infrastructure in multiple homes is smaller. As we grow, these numbers will only trend down.
If I wanted to support this use case today, I would install a very good internet connection in both locations and then bridge the networks using Tailscale so that Roon functions across both locations as if they were one.
First off, big thanks for the response.
Ok, totally helpful - not on the roadmap, and for reasons that I can not only support but embrace. I always assume that you guys have good decision-making, when you outline it I (nearly) always get it. I can get down with this. Again, much appreciate the transparency - it ain’t gonna happen.
I shall try to start reading @Aaron_Turner 's magnum opus thread on getting Roon working over OpenVPN because I have Unifi networks on both ends and pretty good internet connections at both. I was assuming it;d be better to have a core at both ends, but it seems like that’s probably not the direction I oughta be going. To work!
There’s really two issues here (at least two). First, how do you sync two Roon cores and second, how can you use Roon ARC when using one license for two different cores. As @brian explained, the first is an issue people have struggled with since the beginning of Roon. The second is a new issue since Roon ARC came about.
There are two ways I can think of to deal with the Roon ARC issue. My solution was to purchase another lifetime subscription so I can keep my Roon Nucleus activated at home while traveling with my Dell laptop Roon core.
The second way would be to establish a Roon ARC setup at your second home using your second Roon core. As I posted above, that would require that location to have a router setup that would work with the Roon port forwarding requirements. I don’t know how easy or difficult it would be to switch your phone back and forth.
I guess a third way would be the VPN method that I have never investigated.
Hey @brian - You mention Tailscale in particular. Just out of curiosity, does Tailscale do a better / easier job than Wireguard, OpenVPN, L2TP, or other solutions for passing UDP broadcasts? I got close, but am nearly at my wits’ end trying to get Aaron Turner’s excellent udp-proxy-2020 to pass port 9003 UDP packets in both directions across the always on OpenVPN site-to-site that I now have running. So remotes at my second home can see my core at my primary home and connect, but my core cannot see endpoints at my second home (except for the remote in use if it’s configured as an endpoint). If it’s bog standard to bridge the discovery broadcast packets using Tailscale I’d happily sign up.
Thanks!