Except for the „bring back local search“ posts which (for some reason) get immediately moved.
Edit: For context, this post was “moved” - proving the point 
4 Likes
i am based at GMT +530 and its definitely better in the morning for me, when its still night in Europe, but not very early in the morning, when its still evening in the US. 
I do wonder if they had fully thought through what this would take to scale, especially in peak demand times.
One of the neat things about processing everything locally on people’s Cores was that every user foots the bill for their own processing and is largely responsible for their own experience. “Hey want snappier Roon, upgrade your core”.
Send stuff to the cloud and now not only are Roon contending with users complaining about being reliant on the Internet but now Roon, not the users, are footing the bill for search processing.
I can see it being challenging for Harmon to stand by their defence of lifetime subscriptions to be honest. The cost of improvements will be borne in the cloud and will need to be recouped from the entire user base.
With local processing, as it was, lifetime subs are fine as those users do not mean a significant incremental expense, the more you do in the cloud though, the less true that is. The good will from “lifers” funding Roon development will soon disappear amidst the escalating cloud bills.
I didn’t like the move to “always on Internet” as a user but I must say, to give up all that free processing being done by the users in favour of doing it in the cloud sounds like a questionable business choice on the part of Roon themselves.
3 Likes
Back in the 1970’s, timesharing computer users who wanted better performance would come to the computer center at night and submit their card decks, when the computer wasn’t so loaded. One of the reasons the researchers at Xerox PARC were so excited to build “personal” computers, computers where all its resources were used for just one user, was that “they weren’t faster at night.”
History repeats itself.
1 Like
Its already repeating repeating itself. Some are moving off the cloud and back to local, aka Cloud Repatriation.
4 Likes
But it is not only search processing. The Artist view and Album view seems to be now a cloud based call to get the info, like the Artist bio and the Album review. Of course, I am only speculating this, but why else would I see a delay in the loading of artist bio and album review every-single-time. This is not information that will change overnight, so why isn’t it slowly cached locally, i.e. when you visit an artist and an album the first time. Why does the view need to be re-built every single time? It is slow, and it does not improve user eperience what so ever.
From time to time, the cloud can be called to get updated info, or, a timestamp can be checked to see if there were updates to artist/album info.
But why did Roon do it like this? My opion is that it is simpler and safer, and of course this is a speculation too.
If Roon cached the info locally, then there will be complaints of Roon showing old info.
I think the best approach would have been to just use local metadata from the files, in case of internet outage.
And also, to improve the user experience, cache artist/album view regardless of the chance to show stale info. Provide a button to refresh, but show the artist/album view instanteneously, not with a delay as it is now.
2 Likes
In today’s day and age of cloud computing, the key advantage is dynamic resizing of such pools of machines based on load. I don’t know the details of the Roon architecture obviously, but I wonder if there are flaws in the design, eg all processes hitting one database server rather than a sync’ed ring.
My point is simply that cloud computing really does work, and it can be dynamically resized, but I wonder if there are issues with the Roon architecture itself that prevent a seemless scalability.
You could implement, in principle, local machine fall-back - I work in the financial industry and we certainly have that.
1 Like
The real question is why did Roon change TO this as it was not this way when it launched. The move to more and more cloud based services started with v1.8.
1 Like
Sorry for the dumb question, what is TO?
I am a Roon lifetimer only since April 2023, but honestly I did not do my homework well. I believed that the main purpose of Roon was to bring my local library together with an optional online library from Tidal/Qobuz. Turned out online is not optional, and can’t even play my library if offline. Anyways, to the point - I personally think some parts of Roon are overengineered, like artist/album view, and search. Why does search need to be global? Established apps like Apple music, have a switch to say what you are searching - your library or Apples library. Simple.
1 Like
That was me capitalizing the word for emphasis. The point was Roon originally launched with most everything cached locally and starting moving these things to the cloud with version 1.8.
2 Likes
This is absolutely true and if you were thinking of replacing a compute farm that you owned and paid for with this dynamic needs-based rental that the cloud offers - I agree, within use case parameters of course.
But here’s the thing. Roon is not replacing a data centre it had to pay for and maintain in this instance, they are replacing a compute resource that each of us paid for and maintained and were quite happy to.
No matter how good a deal cloud is for an enterprise, it’s not a better deal than “free”, which is effectively what it was for them when we all owned the machines that do the heavy lifting.
They have taken something that was free to them and turned it into an expense, that must come back as user price rises commensurate with that. It’s not a genie that will easily go back into that bottle either.
3 Likes
Yea clear now. I told you it was a dumb question, now that I re-read your comment… I was thinking TO is abbreviation of something.
I will repeat my self - Roon should reconsider and provide local playback without internet. Any player can do this.
Roon should not be an exception, afterall this is on their home page - “your music”… this is not rocket science, a simple switch on/off line can do this, and call home every 2 weeks to check on licence.
But no, Roon needed a glorified album/artist view based on cloud call to get the info every time an artist or album is displayed. And a global search, that does not work regardles if online or offline.
5 Likes
Well, not really. The expense was the great complexity of the variety of home systems they had to understand and attempt to support. The expense was also the limit on user growth caused by the need to have the user understand and set up the necessary infrastructure. Moving to “the cloud” can make things simpler and more accessible. Eventually. If they can find and hire the right people to do the work.
Well we still have to do all that because there is no chance whatsoever that you are going to be able to run RAAT from the cloud, a core is absolutely needed. It’s already quite demanding of the sanitation of your home network. RAAT can’t even deal with being on another subnet let alone across the planet.
SO, you can’t ditch the core, so those machines still need to be maintained.
I agree that they have simplified some of the development but I strongly suspect this is not working out as well as intended.
Time will tell.
But I think they still support the same home systems, they have specific executables for Windows/Mac/Linux/NUC. Database is still runing locally isn’t it?
What you are saying is they had to move completely cloud based, like offload the whole DB to the cloud, so that the local program (Roon Server) is just an intermediary “transpondent” between the user’s files, while the compute happens in the cloud.
This is where they are failing and it shows, all the slowdowns and such.
It is a good idea though, but unrealistic.
Everyone will be better off if the local searches and filters happened locally on the local database, aka the local library.
This is my opinon.
3 Likes
I am rarely critical of Roon. It has transformed my experience of music, and led me down endless, enjoyable, music rabbit holes, as well as a world of hardware discovery. I’m also quite a fan of ARC, despite the criticisms and periodic glitches - they’ve reduced over time and I’m sure will continue to do so.
However, I find it hard to disagree with your statement - expecting new subscribers to pay a premium for a music app that can’t play their music seems optimistic - perhaps there’s just not enough competition in this space? The forum is often full of tales of woe from people who bought items on the promise of features (e.g. Roon Readiness) which are late to materialise, if at all. Established Roon subscribers did so on the existence of functionality that was then removed, which seems both harsh and unnecessary (and I personally don’t see a frozen 1.8 branch as a reasonable alternative).
3 Likes
You are not alone.
2 Likes
They haven’t moved “completely to the cloud” - the Roon database is still local to the Roon Server. There’s a lot that is still done locally. But it’s clear that some of the cloud services are not yet tuned to perfection.
Exactly, and well said. Let’s see, in an imaginable future, when Harman tries to compete with BluOS Node (imagine if they will try, and they used Roon).
You can plug in your USB drive in the Node, and it will play your library no questions asked. Across many rooms, synchronized. And the BluOS interface is not that bad either.
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.
1 Like