Pretty sure it is a bit more complicated than that… My understanding is there are duplicated processes that are hard to change when it requires a release, that are more “dynamically adaptable” if all you have is an API with a single code base running in the cloud: the API is your interface, the calculations/manipulations can be changed across the board for everyone as long as you keep the API paradigm. I get all that.
However, having zero fallback makes me wonder if the Roon team didn’t get too drunk on cloud.
Your cut of that db is local - ie what you have in your library and possibly the customizations (eg album groupings, metadata tweaks, etc).
But there’s a massive Roon master db somewhere. How that massive db is architected (eg one instance with a backup, a global replicated ring, or some other method) is what determines the performance you see at home, I surmise. When you run a search, Roon needs to look for more than what you have locally, hence it accesses the cloud API (API = Application Program Interface - ie a well defined way to talk to code that you’re interfacing with).
A poor-man’s fallback would be to have an intermediate API with a local fallback to search your local db. But I am guessing this was deemed unnecessary, or that it would detract from the selling line “We are cloud based bro!”
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
515
Yet.
I’d expect to see a system where “basic Roon” uses a cloud Server and supports only streaming tracks, with an optional higher tier where you can add a “Roon Brain” to your LAN to support local tracks and/or DSP. Said Roon Brain may be a hardware box, or a much more tightly constrained downloadable executable.
RAAT as we currently know it, anyway. That’s why protocols have version numbers.
Yes I understand all that too - the cost of the development ease you have just bought though, is now something that used to run for free once delivered, now doesn’t.
Well if RAAT becomes resilient enough to do THAT and maintain its currently stated audiophile aims I’m sure we will all be delighted. Or do we just wave the white flag and say, you know what? UPNP would have been good enough all along?
I think I read on the forum, a statement from Danny, that this local search, the “fallback” so to say, was limiting Roon to move forward, and that they decided to “kill it”. I may be re-interpreting, but it was said to be a conscious decision to kill local search.
Edit: which in my opinon is a self-inflicted problem, both could have co-existed, so that local search is indeed the fallback.
6 Likes
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
519
Yes, but no commercial concern wants the former anymore. It’s all about continuing revenue streams, licensing not selling.
I agree. But local search is computationally intensive, and it’s hard to find and hire the people who know how to do it right. Management issues often trump technical issues.
The eventual cloud goal has been in the documentation for years, with the qualifier “not yet there”. But they can’t think just about a year or five in the future. 20 years ago we didn’t have smartphones or music streaming. And as I keep saying, if you read the feature suggestions, a lot of those are not even doable locally, like removing the fundamental (and annoying) distinction between in-library / not-in-library, which has lots of repercussions throughout Roon and is the source of many usability issues. Because removing this distinction and being able to treat everything like it was in the Roon library essentially means just that, having 100 million tracks from Qobuz in what’s currently the Roon library.
Plus I feel this thread is now veering off the original request, keeping Roon at least able to play local music when the internet is down, even if it’s a simplified fallback and no search (or just simple textual search of what’s local like the filters currently). I think that should be doable, but I understand if they don’t want to spend resources on it.
I know nobody who wants stuff like first having to add a track from Roon Radio etc to the Roon library before you can favorite or tag it. Or adding tracks to playlists that are then not in-library. Look at the feature suggestions. What by far the most people seem to want is having the Roon features available for everything that Qobuz has, not just the subset that happens to be in-library. People want stuff like Focus being available for all of Qobuz, and these things.
None of that means giving up the features that make Roon what it is, but the opposite, i.e. extending the Roon functionality to the whole streaming catalog
True, but it can be “solved” easily by setting limits to the local search, for example local search only returned artist and albums. It would still have been something.
But in all honesty, if local playback offline was the goal, it can still be provided by disabling search alltogether and falling back to filtering and/or just browsing artists and albums. You just navigate somehow to the content you want and hit play.
But, in my personal opinion, it is not that playback is not possible offline, Roon now can’t present the artist or album view offline so that you can hit play.
If you read the top of the thread, it meant “let me play local music when internet is out”
Out of 300K users. And if you read the thread (and others from the time), I very much agreed that using Roon basics when internet is out should be possible. Certainly lots of people want that. But the thread for most of its lifetime was never about not having cloud search as such.
Unfortunately, (as was pointed out around post #100) the thread title made that unintentionally ambiguous, when it only meant to say “let Roon play my local music even if that necessarily means only local search in this case”
I suppose they don’t find it worthwhile to spend development resources for something that they may view as a topic of diminishing importance. But I am not Roon.
Anyway, that’s not the same topic as “remove cloud search, I hate it”, and really the whole argument has been rehashed over and over again when it was new and later, and the old posts didn’t disappear in this thread (including justifications by Danny, if you agree with them or not) and in the ones linked at the top (except the last one in the list):
Of course they are somewhat related, IMHO mostly because of long-term visions and the impact on development resources, but Roon should not be totally cloud dependent if internet is out and should allow at least basic playing of local files is not the same thing as even if internet is available, the cloud is a bad idea and should not be used
Having said that, we have had the position stated a number times on both of these related threads that the need for persistent Internet is because of the move to cloud, they are in fact linked.
I think many people’s position, somewhere between 1000 and 1500 forum users as you point out, the most significant statistical sample we currently have for a feature request could probably say “provide local playback that can withstand Internet outages and feel free to use as much or as little cloud as you like guys”.
