Roon 2.0 and internet connectivity [it's just like 1.8 now]

So there may be bug to report to Discourse here?

I think that you are correct, I have a main system in my study that I use for critical listening from my ripped CD’s/hi-res files and then I have just recently integrated Roon to stream across the apartment within my intranet for more casual access to music.

I hope that your needs can be resolved as soon as possible and I hope that I haven’t added to your stress about this matter.

I voted on the feature suggestion posted above. If people view this as important, it’s worth voting this up! I can certainly understand the amount of additional work it takes Roon to make their software resilient to outages, and behave correctly. However, I’d hate to be without local music if I have an ISP outage, or any other scenario where I may not have internet for a semi-extended period of time.

3 Likes

I think this post was guaranteed to make a few people angry :laughing: Local software and local files are the main feature for some people, including myself. In this initial statement, it’s really not obvious why the change was necessary, and the phrase “substantial period of time” could mean anything. I appreciate much more the later clarifications that begin to address these. I think very many people in these forums are techy enough that this sort of message should be the tldr to a much fuller story.

I think the most important question is “How do we listen to our music with no internet?” Can we easily switch to 1.8 if 2.0 goes down, to provide a fallback? As far as I can tell, 1.8 will need to make a similar connection for its first startup, so it wouldn’t work except in a planned outage. Is there a solution for this?

I’m pretty interested in how this unified engine might work that it couldn’t continue to work if online sources were simply treated as empty if they became unavailable. The only reason I can think of is that Roon now transfers data from the local music database to the unified engine running as an online service. So beyond the inconvenience when the home internet goes down, does this also mean that if some server goes down the other side of the world, we can’t listen to local files? With internet latency it would also be debatable if it makes it faster. Perhaps I’m mistaken…

In principle I appreciate that you’ve got to abandon some things to make future development easier. But this is still a bit too vague to be comforting, because you don’t specify what upcoming things this sacrifice was for, and it doesn’t really make sense (without further detail) why there’s no fallback left in place when you evidently have local search code that does the job and presumably already has automated test coverage so not a huge thing to maintain.

This change will affect me a bit I’m sure, but it’s not enough of a problem to put me off what is still a great bit of software I use all the time, and it’s really commendable to be at all open about internal architecture. But the change does put a little unease in my mind - what will be the next sacrifice for unidentified ‘progress’? Move entirely to the cloud? Adverts between tracks? Drop local file support? Well, if there’s a market… so long as it’s in very much separate products, fine with me. I just hope ‘local only’ users will always be considered worth providing for.

4 Likes

Earlier this evening I tried to change it from Muted to Normal, but it wouldn’t let me (iPad 7th gen, iOS 15.7).

@danny how long will 1.8 be around for? I’m a little stunned. I’ve been asking in other threads for there to be less stringent license checking as I get punished far too often as a paying software user with buggy license transfers between cores.

1 Like

I also voted in favor of Roon restoring access to my personally owned and locally stored music without the need for continuous internet access.

Given the speed at which this topic has accumulated comments on this forum and others, I have very likely missed some relevant content, so apologies if I’m addressing moot points or repeating points already addressed, but a few observations at a higher level and with a longer term view…

  1. There is likely a “lessons learned” opportunity here in terms of how feature requests are evaluated and then prioritized for work. It’s one thing customers to ask “do you want feature X” in the absence of an associated cost or consequences. It’s more informative to ask “do you want feature X if it impacts existing capabilities A, B and C”. Perhaps this was done already and wasn’t enough to alter the approach, but for the record, I very definitely would accept less ideal search to continue enjoying the ability to play my locally stored music without any external dependencies.
  2. From a developer’s perspective, I understand the appeal of moving functionality to the cloud, but I would suggest that this should not be done lightly and that you need to consider the implications over a very long time horizon, including beyond the current team’s own involvement. In particular, I hope that you’ve hired dedicated information security experts to assess both the architecture and software itself, and consider how to manage the use of customer information involved in enabling this approach.
  3. I’d suggest that more transparency is needed in terms of what data is exchanged between customer systems and Roon’s cloud services. Certainly I’d encourage this to be minimized and not in any way tied to our account information. For example, when I search my local database, does the search request hit your cloud servers with my license or any other identifying information attached? Is it encrypted? Do you retain that information? If so, why, how long do you keep that data, in what country do you keep that data, and how is it protected?
    a) Yes, I see your privacy policy statement that “Information about how our members use Roon is not transferred or stored with any member’s personal data” but I also note that your policy has not been updated with the release of Roon 2.0. (It’s still dated May of 21.)
    b) Yes, I know that it’s “just music”, but in the era of big data and machine learning, it’s not “just” anything any more. At least, it has the potential to be more at some point. (Think about the sophistication that psychological profiling has achieved “just” by being fed our online purchase histories.) Remember that by moving information to the cloud, you’re asking us to trust both your intent and execution not just today, but to trust you and your eventual successors intent and execution forever more.
  4. Similar to (3), I’d suggest that more transparency regarding how our local networks are penetrated to enable these services would also be helpful. I’m not an network security expert, but I pay attention to how my network is configured, what services are running on it, and what external access they need. I’ve avoided many products and services because I determined them to be insecure, or insufficient information was available to make this determination.
    a) Like many, I blindly upgraded because I had long since come to trust Roon. Had I better appreciated the full scope of this very fundamental architectural change, I would have asked these questions in advance.

The takeaway here is that the fundamental shift away from using local services to manage our local music is not just the functional consideration that has been well characterized by others, but also requires a significant privacy and information/data security assessment.

(To be clear, I’m not a fan of the functional dependence on internet connectivity either - I just don’t feel the need to reiterate others’ points. The one subtlety that I didn’t see mentioned yet is that we need to remember that this architectural change added not just one new single point of failure - our personal internet connections - but two. The second is Roon’s own cloud service reliability. The end-to-end system resiliency math needs to multiply those together. I’m sure the probability is low, but imagine the reaction when Roon’s cloud services eventually experience an outage…)

A final comment… I don’t currently have time for forum posts such as this. The fact that I’m doing so reflects just how much I’ve enjoyed and respected the product for years, and the fact that I really do want to see it continue to flourish. These comments are offered in the hopes that they prove constructive. Thank you!

7 Likes

The decision that the Core needs an internet connection at all times stuns me.
I am a lifetime member and you make the product unusable for me in many situations - overnight. Why all this? I’m disappointed.
Daniel

2 Likes

It’s unlikely to affect me that much personally but I can understand the frustration for anyone who has been using Roon without internet until now. I hope something is done about it. There’s a thread where you can add your vote to show your support for this issue.

https://community.roonlabs.com/t/make-roon-play-local-music-files-w-o-internet-access/214998/32

1 Like

I don’t quite understand this. Does this mean that I won’t be able to use Roon when my internet is down? I’d like to be able to access my local library regardless of my internet connection.

1 Like

I agree wholeheartedly on this one.
A few weeks ago i had a “blackout” and was out of internet access for close to a week.
My Core was up and i could listen to my local library, which was a trip down memory lane.

Roon for me is a domestic music enabler, not an “on the road” music solution.

6 Likes

I’m disappointed for all the reasons I’ve already stated, but I was only on monthly renewal so I’ll just go back to other solutions. No big deal. But if I were a lifetime subscriber, I’d be LIVID.

I think more and more people are going to upgrade to 2.0 without really thinking about it, then their Internet will bug out, and they will realize they’ve paid many hundreds of dollars for the privilege of being cut off from their own music collections, and their response will not be pretty.

2 Likes

do we Roon users/customers realize that thanks to this new appreciated features “always-on-line” in praxis Roon is stopping from remote our possibility to run our NUC, buyed only to run their software (ROCK) and manage local library too, limitating in this way in a very bad way our rights?

somewere above they justify this with a new scanning engine running only in their powerful servers… but once I’ve already scanned all my library, both online and local, and saved in local backup all the info, covers … settings… payment status… etc. etc., where is the problem if I run only my local library offline using all the info about that already stored in my hdd?

why they are so interested in having us always locked to their servers?
why they didn’t informe us about this bad limitation in advance? before being forced to update
Roon do not supply us a service and the hardware to run itbut only the service and we use the service to scan our local library and store info about inside the hdd/NUC we payed for… why they are forcing the value of our hardware to zero with this new unpleasant feature?

1 Like

See:

Lifetime user since day one (or two, maybe). Use roon to distribute a pretty large local library inhouse. Love advanced search and integration of streaming services.

But I am really lost at the decision to make internet access mandantory. Basic search (artist, album, track, whatever is in local tags) is a no brainer.

In case of internet outage I need to be able to play local files via roon in a fallback mode at least.

2 Likes

Let’s not be blue-eyed and believe that the search function plus arc are the only reasons for permanent iNet access. In my opinion, equally important is licensing, because a 1 month offline grace period makes sharing a license easy. This is a legitimate concern of the company. Imo a strategic shortening of the offline period to let’s say 24 to 48 hours would make most license sharing difficult if not impossible. 1 to 2 days of grace would also cover the vast majority of outages that exist.

Those with a desire to use ARC, of course, must stay 24/7 online, even though I don’t really understand ARC. If I want to listen to my music while travelling, I can always use the streaming services of Qobuz or similar, where–I am sure–99% of our local music are available 24/7. Using existing streaming services would make online access to my private library obsolete. Those who don’t have a streaming subscription, of course, are the only addressees for ARC, who are probably very few.

1 Like

I can not find this thread on the Roon Software main page. For me it ‘disappeared’ some time yesterday afternoon and since then I can only find it using the search or through my own activity.

Since this topic is one of if not the most discussed since 2.0 release, I think it is important it remains in public view.

If I am just being blind or stupid please tell me where I can find this discussion without resorting to the measures above.

See the post from @AceRimmer above in this thread. It seems to be some quirk in the forum software - perhaps because the thread seems to have got marked as “solved”.

https://community.roonlabs.com/t/does-roon-work-without-internet-answered-no/153218/480

1 Like

As a side note to all of this…

I think if ARC is improved and when it comes to tablets, and the 14 day grace period stays. Then, that would keep me happy enough, as we’d still be able to play our local music.

There might be improvements in way of a desktop application. I can even see ARC replacing the remotes as our all in one app (be interesting to come back to this topic to see if that happens).

We’ll just have to wait and see.

Thanks Geoff, I did read that, but for the reason mentioned, should not somebody go ahead and manually restore it so everybody can find it? I am not familiar with this particular forum software, I only know phpBB from an administrative view, but my guess is it should be possible. Is it?