Feedback / question - Multiple Cores for Arc?

[brian (Brian Luczkiewicz)]

@Johnny_Ooooops

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.

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:

1. It is a very complex and costly feature to build
2. It creates a “tax” on everything we do afterward, as everything needs to consider location sync.
3. It is costly from a QA / support perspective because multi-location setups are complex to create and recreate when troubleshooting.
4. 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.
5. Multi-location setups are an absolute nightmare to support because the user only has physical presence in one location at a time.
6. 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.