Would you please understand what you are saying is:
1- Absolutely obvious and pointless
2- Misses the point completely
I try to keep it cool but really I am starting to get annoyed.
maybe there could be a win/win situation here. Roon wants to move to targeting a cloud platform to streamline their development, and make use easier for new, and non technical customers.
If that is the case, could roon make available a docker / container file for their cloud server instance, so that I could run that ācloud serverā in my home?
This is the idea of a dedicated server. Most customers wouldnāt have to use it, but customers that want it, could.
I donāt think this is a good idea: on top of fragility youād have more latency. Plus you would always need some form of bridge between the cloud code and your local network.
Well, we already have something called Roon Bridge.
That is not the same thing. That allows your device to work as an endpoint.
Well, thatās what it does right now. But what does that mean? It means that the bridge can access the network ā and the Core can access the bridge. Suppose the bridge could reach out, instead, to a Core in the cloud. The bridge already pulls data from the Core to play it. Why does the Core have to be on the LAN instead of the WAN?
It would be a nice convenience option for many customers, to not have to have a Nucleus or other Core machine in-house. Maybe that kind of setup would only support RAAT. But that would probably be OK, too. After all, there are lots of Roon Ready devices already, and Roon Ready streamers for devices which donāt already have Roon inside.
As for latency, Iād say that the various other streaming services have already demonstrated that it is not an insuperable problem.
Get it on the roadmap and get it fixed, please.
1 Like
Well it is unclear the Roon team sees it as an issue at all.
1 Like
Happy Thanksgiving to those who celebrate!
Iām thankful for family, friends, a warm home, and music to fill itā¦
Also thankful for choice. My Roon subscription is cancelled and Iāve moved to a platform thatās continuing in the direction I prefer. I wasnāt a lifetime subscriber but Iāve been using Roon for years and was heavily invested. But none the less, I encourage others to just walk away rather than beat a dead horse. Re-purpose your hardware and move on. Ultimately Iām happier for taking matters into my own hands.
And always be thankful for what we have.
-S
8 Likes
Absolutely spot on! Couldnāt agree more with this sentiment.
Roon has effectively turned our music libraries into something we have no control over
5 Likes
I agree with this characterization.
However, it is easy to think that simply removing search when the internet is out is an easily accomplished task. In reality I donāt think it is. My read is Roon made the decision when they started writing 2.0 to rely on cloud-based APIs liberally. This means the Roon code calls these functions liberally everywhere - and these functions can ONLY work if thereās an internet connection. Reworking the code to be fault-tolerant to no internet is probably a fairly complicated task.
To be honest, I think the decision is an incredibly bad one - and makes me question the quality of the Roon development team and more so the skill of the management team not to see this issue right away. I would venture it was a cavaliere decision without a lot of thought - an issue that could have been avoided with more careful design. But now the team is knee-deep in this decision. In my opinion, at a large software firm, this would result in those approving this decision to be dismissed. But we are talking a tiny team here, so you fire danny and youāre out in the cold.
2 Likes
The Roon team has proven to be incredibly sharp and resourceful. I doubt they expected anything like the customer reaction theyāve received on this. IMHO, Iāll be surprised if they donāt come up with a way of dealing with offline internet and local music. But it does behoove them to make a formal statement of their intent on this issue. (If they already have, I havenāt seen it).
I, for one, will undoubtedly stick with Roon 2.0 (and beyond), but Iād also seek my own alt solution for the times the internet is offline. Perhaps just keeping 1.8 Legacy installed on a spare laptop ready to go would work fine. I havenāt tried it (yet) but I would if I knew a 2.0 solution was not forthcoming from Roon.
Having a spare 1.8 is a good idea (may do the same). I guess the issue might be that you canāt login / switch the license over from 2.0 if you had already lost internet connectivity.
I think this issue can also be viewed in a broader light. It seems to me that even pre-2.0 versions of Roon were also overly reliant on your network connection at home and didnāt do much/enough caching, e.g. for the structure of your database and cover images. Whenever the connection is for some reason slower than needed, issues and slowdowns occur.
Iām trying to use Roon ARC on the go as much as possible to see if itās a suitable alternative to my music player with locally stored files. However, it sometimes fails to just load my music library, loses cover images, or is generally slow in loading up the structure of my library. The offline toggle fixes some of this, but not all, and it doesnāt make much sense to me that I have to tell Roon it shouldnāt be looking for my core when Iām not on 4/5G or Wifi.
I donāt know if this can be generalised, and donāt mean to offend the Roon team, but it seems that it has to do with little consideration for fault tolerance and robust design and development in Roon products in general. All my Roon clients, be it Roon for desktop, Roon remote on two Android devices or Roon ARC, crash or lock up frequently, generally more than once a day. More than anything, Iād wish the Roon team would invest in making more robust products.
3 Likes
It seems that with these constant upgrades, itās like we are using a beta version. However it also looks like Roon is addressing this very issue with the launch of a Qucik Access program to assist with beta testing prior to release.
This is a good move on Roonās part and it shows that they are listening.
Here is the category they created for it. Do not know if they are still inviting new users or not in case you would be interested.
āMD
Early Access is a great idea for a wide beta testing. Iāve found it easy to switch between Early Access and Stable Release. One thing Early Access (from B1159 onwards) has shown is that album and artist information is going into the cloud, away from local database. This is consistent with Roonās reasoning for moving away from offline availability.
That raises an interesting question that can easily be tested. If my Internet is down, can I still start 1.8 Legacy and is it still able to see my Roon 2.0 core on my LAN such that I can switch my license. If not, then there goes that scenario.
It would be good to test.
But my guess is it wonāt work. I have two roon licenses in different buildings - and when I log in Roon checks centrally and if both are being used - tells me where. So that login process is clearly checking with a cloud server.
And I should add: There are programming paradigms to avoid this issue while relying on cloud-only functionality. For example, make the API make a local call with handling of no internet connectivity. But you have to make these design decisions early on or youāll be in a world of hurt later.
2 Likes
I seem to recall reading something along the lines that the Roon team were surprised there was less pushback on this than they were expecting. I interpret this to mean that they did predict this was going to get a negative reaction from customers, yet chose to do it anyway.
I hope that interpretation is wrong. If true, that honestly makes me more disillusioned than the loss of functionality itself.
I also hope my interpretation is wrong as it would further imply that there are no plans to fix this, as it was a deliberate design choice and not an oversight.