Roon 2.0, Internet Access, MacOS requirements - I'm furious

Hi Jim, Well said. Im going to do the same but will not update to 2.0 until I have my alternative set up and running. Looking at Audirvana Origins and Jriver. There is also iTunes/Music. I will play with all three and then decide the best alternative. All the best, Ron

1 Like

Dependd very much on the options you determine most useful - for me its multiple zones and device control that I cant quite find in other products. I don’t have that much old hardware and I do like ARC a lot too. I’m also a lifetime user of 5+ years so have my ROI already. I have very stable internet and I can fix most issues without support assistance.

Granted not everyone will have this view but I’m guessing its the minority that is really going to be affected.

I still Roon think could have done this better and had a “crippled” mode for when the internet goes away (or roon even if that ever happens) as their cloud systems have indeed failed in the past too.


I would agree with you that the multiple zones and device control are unique to Roon and one of the things that I love. Those functions are really unique to Roon. With that said, if Roon still supports local libraries and then basing the software solely on continual internet connectivity is not wise. I am a Roon lifetime member also and the software is a big part of my families everyday use. As you suggest they should have or should soon allow a reduced mode so we can listen to our local music “off line”. That would make our lives much easier and those of us that have issues would not be forced to scramble to find an alternative. Have an awesome day!

1 Like

Ron puts it well, and nicely. But i think he let’s them off way too lightly. My #1 long term concern is the “must have internet”. I hope the market (that’s us and many more) make them rethink that. In the near term the fact that they just made most of my control points, and cores-on-the-road obsolete, so that they could simplify their programming life with the latest version of .NET, is annoying and costly, but ultimately livable. but not being able to play music after a storm takes out internet, when on a plane, when at a mountain cabin, or when there’s a simple glitch (yea, i do have a fiber to my main house) is just bad. And totally needless. I re-iterate this is all about copy protection - which in most software died decades ago.

I even have nothing to gain - i paid up front for a lifetime of use. You know, like a product!

Roon sees ARC’s offline feature as a solution to this, because, well, we all have gobs of unused memory on our phones (or plenty of $$$$ to run out and buy a new phone with more memory) just for this purpose. :roll_eyes:

1 Like

It is discussed here as well

I don’t think anyone should presume to know why Roon is going this route other than what Danny has posted. Nor do we need to know. Just figure out how to deal with it.

OK post must be 10 characters. Now it is.

Why not? We can also influence their decision, if enough of us complain, and they think it will legitimately be to their detriment…I have always said i have a love/hate relationship with Roon. They could make it love/love. I want to love it, its just so difficult sometimes.

1 Like

It’s already been said by Roon (Danny?) that the pushback on this issue has been less than they expected. So it seems there aren’t enough complaints to change Roon’s position on this. :frowning:

At least one person was banned from this forum for 90 days for posting falsehoods about Roon and their motivations for this.

When we started out, it was UPnP support… then it was folder browsing of files… then it was “beta” quality uncertified Roon Ready devices… etc… it’ll always be something because we are making decisions that allow us to continue to fulfill our vision of what Roon should be, and many of those decisions are against the grain of what is expected today.

Not on this subject.

And there you have it. Case closed on this subject. :wink::+1:

1 Like

It is not about copy protection. But, if your mind is made up we won’t bother you with facts.

1 Like

My mind is not made up. I WANT to use Roon… and for now am using 1.8L.

I just don’t see any technical reason not to support users with the basic operational model that has been in place since day one. Remember that many of us have made investments in equipment, setup etc., under the assumption that Roon would continue – with improvements – but with the same operational model. We have a lot invested and a lot to lose if we must abandon Roon and start over.

Some of us, like me, believed in the promise and gave Roon a significant payment up front for a lifetime liense. We are impacted even more, and frankly it hurts since i assumed the trust and obligation worked both ways. We want to see Roon succeed - but this really makes it very hard, especially for those that have large libraries locally and use roon as a multi-room and library.

I just cannot see how any feature that demands internet access (cloud analysis, cloud data) cant simply be unavailable until the internet returns. There are many reasons - LAN failures, WAN failures, taking roon “on the road” etc. For example I recall when i moved, and internet lagged my moving date.

So why did i assert that this is license protection related? Through the process of elimination, i came to the only solution that really made sense to me, and no one has provided a plausible alternative. I have architected several high availability industrial apps an know that they can certainly be made state-aware so that they operate differently when some data or function is not available. You could too. Having a general failure, due to one outage is generally considered just bad design. So other answers – as i wrote once before - -simply do not add up. And none of this explains why you rule out future support of “offline” use. Finally none of this explains what reduced functionality could not be maintained with older remote versions that run on pr-10.15 macs and pre-WIN10 systems.

So, open the door back up and we’ll likely feel a lot less misled and let down.

I truly hope to be wrong, and hope that Roon will surprise me with reinstated support at some point in the not-too-distant future. But the answer provided me was unambiguous.

Please rethink it.

1 Like

Seems to me I’ve heard several. The speculation that seems most likely to me, remembering that Roon 2 is not Roon 1, would have Roon moving the Core to the cloud. No more local Core machine. The UI, and RAAT bridges, will just talk to the cloud. Many many current problems would disappear.

What happens to local files if that transpires? Again, one could see several different alternatives.

1 Like

When i said “no one” I meant “no one in a position of authority at roon” has given a plausible explanation of why they cannot support local operation.

Now when you say the core moves to the cloud:

  1. my local files cannot move to the cloud
  2. The RAAT server cannot move to the cloud
  3. Based on #2, it would be very difficult for DSP to move to the cloud

I guess you could move DSP, but why would roon want to pay for all our cloud computing? And if they tried to charge, what would all those who invested in NUCs and Nuclei per roon’s suggestion think?

So what would move? Corpuses of metadata? Corpuses of analytics data (already there)? Those are exactly the sorts of things that could fail and be “unfortunate but no big deal temporarily if the (local) music keeps playing”


You make some excellent points! But I think you’re wrong about the RAAT server. There’s a latency issue, to be sure, but other music services do OK running their servers in the cloud, so why not Roon? All the DSP, etc., could be done there. The price of cloud-based computation is trending towards zero, after all.

There are still issues which seem to me to make it difficult initially. I don’t see how endpoint discovery would work, for instance. Maintaining endpoint group coordination would be a good trick without a local coordination point.

As for buy-in, if I were doing it, I’d offer an opt-in “Virtual Core Machine” which you wouldn’t have to maintain/operate, perhaps for a slight additional monthly fee, perhaps for a single payment, say the cost of a Nucleus. Users could either stick with their local Nucleus or NUC or whatever machine, or simply have Roon do it for them. ARC would mutate into a full-fledged version of the Remote, and as we know, ARC need not be on the LAN the core is on.

Let me point out again, this is all just speculation.

How much do you know about how this stuff works? All streaming services have some form of local client - whether a browser plug in, client etc. RAAT does a LOT - and you need something local to take the stream, error check it, buffer it, maybe multicast it, blah blah. We’re not talking low quality here, or certainly i’m not and many are not…

You need a local server. In this case its RAAT. Could they further break it down? Sure. But think about the trade offs. I’ve built stuff like this (vastly less extensive, yes, but i’ve built them).

Again, how much processing do you expect roon to provide for free? Nothing’s impossible, but its very much unlikely. Plus then you have not a demand for internet access, but fast, relatively low latency internet access and have ruled out many, especially rural. It only makes the dependency worse.


Quite a bit, in general.

Yes, and in my scenario, Roon Bridge (and its analogue in Roon Ready devices), and perhaps Roon Remote, would bulk up a bit to take that on.

None, really. There would either be an additional fee for the “Virtual Core Machine”, or it would be covered by the subscription price, as is done with all other streaming services. Maybe an ad-supported tier.

Indeed. That’s a big drawback to this scenario. Insoluble? Again, counterexamples already exist.