I love Roon. Roon core on Mac + 1k classical albums on NAS + Lumin T2 endpoint is pretty much 80% of my listening. Don’t use Tidal/Qobuz, Nucleus, ROCK, HQ player, Linux, windows, Pi, metadata editing, custom installations and the billion settings and features.
This a simple setup. I’ve had zero issues with Roon in the two years into my lifetime subscription. But I see lots and lots of people with lots and lots of issues on this forum.
This makes me think: Is Roon trying to do too much and please too many people? Maybe it’s not a big deal because the feature set and platform support is so huge that people are willing to forgive then for all their bugs and transgressions. But still… it seems that that should concentrate on just making the thing solid before supporting any more Roon ready devices, new features etc.
I’m a computer scientist and have been working on complex software for 30 years—easily more than 20-30 million lines of code in all cases. The first rule is: keep it as simple as possible when designing the feature set and the architecture and then implementing the algorithms. (And in a lot of cases we’re the first ones to be designing the algorithms, so there’s no prior art.)
When I see all the knobs and settings and platforms they support and devices and protocols and on and on, I’m not surprised that anytime there’s a software update people start complaining on this forum.
Am I missing something? Is it a misimpression?
4 Likes
Torben_Rick
(Torben - A Dane living in Hamburg - Roon Lifer)
2
That would be very nice I think Roon ist great - but concerned about any update (Windows, QNAP, Roon etc.) that comes: Will the update create new problems?
Are you a theoretical computer scientist or did you ever have to sell a product?
Like most nontrivial applications, each user may only use 10% of the features, but everyone uses different 10%. For myself, Roon would be useless without Tidal/Qobuz, metadata editing and some of the billion settings and features.
I’m not sure how much the support of Roon-ready devices complicates development. I hope there is a clean interface and the answer is “very little”
In any case, not supporting the features users want, and not supporting new Roon-ready devices asap as they enter the market, would be the express way to killing Roonlabs
All production products. (Believe me, no academia has 20 million lines of code as mentioned.) These are all products used by major chip companies to verify their chips
Every one of our customers has its own requirements and features they want. But I’ll tell you one thing: if at every update the thing broke on their chips, we’d have been out business a long time ago.
I don’t care how wonderful Roon is and how many things it does. Something is wrong if it breaks so often. That’s clear. Either there’s continual feature creep, they didn’t anticipate the needs of their basic architecture or they don’t spend enough on continual rearchitecure. In fact it’s very difficult to do the basic R&D if you’re continuously fighting fires. Which is what it seems to be doing.
Maybe, but this is a support forum, and the number of people who post with specific issues, are often infrequent visitors. Moreover, this is hardly representative when you consider Roon has around 300,000 subscribers.
I’d say that most issues are resolved, are typically networking related, and include setups that are overly complex, not because or Roon, but because the user choses to do things this way.
I argue that Roon is restrained in this area, and doesn’t implement options unless absolutely necessary.
Regarding platforms, Roon supports Windows, Mac and Linux, but not desktop GUI. They are state what variants are supported, including hardware and software versions.
DACs can be Roon tested, but many work out-of-the-box. Likewise, network streamer are RoonReady or utilize Roon Bridge. IOW, not so complicated as you suggest.
There isn’t just academia where products don’t have to be shipped, hence my question. Anyway …
I think both of these may well be correct, few commercial products spend enough on that. In any case, removing features and not supporting new devices that customers bought / can buy, as you seemed to suggest, is definitely not the way forward.
As Martin_Webster wrote above, I wouldn’t take the number of support requests on a support forum as an indicator. I, for one, have used Roon for 1.5 years and though I had the odd feature request and minor niggle, it has been solid in practice in all this time
Too late to remove features and not support existing stuff. But don’t do anything new until you fix whatever is wrong if things are at bad as my impression is…
But again I could just be wrong which I’m happy to accept.
I also don’t think that someone working on, say Roon OS 2.0 and UEFI support, or low-level networking improvements, is the same person that implements search improvements or UI features, so I think there can be some parallelism.
There’s the difference right away. With CAD/CAE software, where each seat goes for $XXk, all parties involved agree on implementation (minimum hardware requirements, OS, …) constraints to minimize surprises. Roon doesn’t have that luxury. Most potential Roon users are not going to completely replace their computing/networking/digital audio to meet a strict set of requirements, so there’s a long tail of unusual/not up to date/buggy hardware and software that interact in unexpected ways with Roon. Having said that, as a long-time Roon user:
Roon’s reliance on .NET as a framework increased portability at the expense of reliability, especially since it created a dependency on the .NET clone Mono that was never as reliable or performant as MSFT’s .NET. That is being resolved, for instance Linux .NET was a big win for those of us who run Linux cores, but still not complete (macOS, Apple silicon).
Roon’s reliance on IP multicast for discovery sometimes tickles the multitude of buggy multicast implementations in consumer networking hardware. Arguably there might be more robust solutions now available, via mDNS for instance.
3rd party protocols (Airplay, Chromecast, Linn streaming, …) have undocumented quirks and bugs that can trip Roon.
But I certainly think there are too few support employees to handle the volume of support tickets. The silence and/or inaction on issues sometimes seems like they are indifferent. I think it is more that there just isn’t enough people working those tickets, and I really think that needs to change.
I agree. Too many, “We’re sorry,” and not enough timely solutions. Problem is, every new employee is probably close to $100,000 (salary and benefits) out of the pockets of the owners or 800+ new customers.
As another veteran computer scientist, everything @Fernando_Pereira said is correct, but even tighter for enterprise software: 1) here’s the list of supported Linux distributions, often starting with RHEL, and maybe one or two more, and specific versions of those distributions; 2) here’s the supported hardware list: Manufacturer A, models X, Y, Z; Manufacturer B, models U, V, W. (These days, instance types in AWS, Azure, Google Cloud, etc are also likely to be listed.) If you’re running on anything else, no support for you.
Life is different in FAANG land, for the most part, which is why ARM servers are rolling out in the various clouds first before widespread on-premise use.
Roon, as previously noted, doesn’t have this luxury.
It’s not an invalid point. However, although our software domain may not have such machine, OS, inter connectivity issues, we’re have lots and lots of compatibility and inter-operability issues in other areas. So I’m not yet convinced that this lets them off the hook.
I guess my bottom line is that if repeatedly you’re breaking stuff that used to work in serial updates, there’s something wrong. You can’t just rest on the “look we have so many things to support” argument. Figure out a way to architect for every scenario or support a small subset of use models
But are they? Don’t forget that everything is changing around too. People with issues say “but nothing changed in my system” except for OS updates, new router firmware (often not known by them because ISPs push it regardless), ditto for digital endpoints, just one additional managed switch in the closet, changes in their WiFi environment when a neighbor with an out-of-spec access point moves in, intermittent ISP issues (don’t ask me how I know about this one), … Of course one can always try to do better, but the sheer variability of domestic computing and networking setups is far beyond anything I’ve experienced in 4 decades in telecom and tech.
I would say the community “solves” at least half of the issues on the forum through the holy trio
Reboots
No, you need a server and it needs to meet the minimum spec not that core duo
That doesn’t work with that
Then there are network issues.
Users are buying, due to some of the reasons outlined above, a heavily network dependent product without sufficient/any research. Users have misconfigured or misunderstood the kit they have bought or rely on underpowered ISP equipment.
If you then take out the noise of “Roon doesn’t work exactly as I want it to”.
You are left with the actual bugs of which the vast majority affect a small amount of users and roon deal with in regular updates.
I think Roon ist great - but concerned about any update (Windows, QNAP, Roon etc.) that comes: Will the update create new problems?