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.
LOL
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. 
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. 
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:
- my local files cannot move to the cloud
- The RAAT server cannot move to the cloud
- 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”
Justme
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.
Justme
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.
How about @brian 's “Input Device”? Something that would take turntable or tape deck inputs and integrate them into Roon streaming to Roon endpoints.
It’s been a longstanding dream of ours to build this kind of networked routing. It’s something we would really like to do at some point.
In the future, local files could be considered just as obsolete as vinyl, so imagine an Input Device that you could plug turntables and tape decks into, but you could also plug USB drives with ripped music files into it. It would synchronize play from all of that with a cloud Core server, for local play on your LAN.
We are all affected the same. The fact that some of us paid for lifetime was our decision. We are not more affected than someone who pays monthly. We may feel more “locked” into Roon, but again, that was our decision.
Indeed. Spilt milk. Sunk cost.
1 Like
I see this thread is hidden. No wonder no one is posting!
1 Like