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

[Daniel_Houghton1 (Daniel Houghton)]

@danny

With the Roon Core on version 2.0, the grace period is not 30 days anymore. You must have internet access to run the Roon Core 2.0. If you require offline access for any substantial period of time, you must stay on 1.8 Legacy.

I think this post was guaranteed to make a few people angry 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?

@danny

This is one of those many reasons: we used to have two search algorithms. One ran locally and one ran remotely. The local one was quite poor because it lacked the infrastructure to keep a good search engine operational. But because of offline support, we needed to keep both functional. The online one keeps getting better but the one that lives in the Core hasn’t been improving at the same pace. Search is a major pain point for many of our users and it’s a shame because many of those same users are using the local engine often. On top of that, being, consistency is extremely frustrating. With 2.0 we killed the local engine. So now all search requests go through a single unified engine that will continue to improve. But if we advertise offline support, then search has to work offline, which has been problematic.

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…

@danny

This is one of the reasons, but this is an architectural shift that allows us to make improvements and shed some of the limitations that we’ve been constrained by in the past.

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.