And The Answer Is

Reboot, reboot, reboot, and reboot again.

And the question is: What should you do when you have a problem with Roon?

Probably 80 to 90 percent of the problems can be resolved with a reboot of your router, Roon core device, Roon bridge and/or end-point devices, and Roon controller devices.

What you say is definitely a way.

The problem is that it is also a failure on the part of the ones who wrote the code.

In any competent software, rebooting is never an acceptable solution.
Particularly when, in the case of Roon, it (conceivably) requires rebooting so many different devices.

Sorry to Roonies for that assessment, but lately I’ve become disenchanted due to some of Roon’s inadequacies.

3 Likes

I don’t know, but anytime you’re dealing with computers, things can go haywire. Rebooting fixes lots of mishaps.

1 Like

I find that I have to restart Roon on my core every week or two to deal with issues that pop up. At this point it’s a minor annoyance, but I would hope that Roon would be a bit more reliable at this point.

Rebooting everything once a week might be a good thing. Clear out the cobwebs.

My core is on a NAS which is scheduled to reboot automatically once per week. Some other equipment might allow that.

My Raspberry Pi 4 with RoPieeeXL reboots every night. I shut down my laptop, iPhone, and iPad every night. The only thing that does not get rebooted very often is my Nucleus.

The only time any of the computers in my house (an Odroid H2, an Odroid HC1, three Raspberry Pi’s and various Apple laptops) gets rebooted is when a system upgrade requires it. And I’ve never had to restart RoonServer or RoonBridge in between reboots.

Just lucky, I guess …

P.S.: Running RoonServer and RoonBridge as an ordinary unprivileged user, instead of as root (as is the default) is one thing which may contribute to overall system stability. If you’re at all dubious about the stability/reliability of either piece of Roon software, then you definitely don’t want to run it as root.

1 Like

Maybe the problem is with the shell Roon uses for its platform. What is it: Chablis, Chardonnay, Mad Dog 20-20?

4 Likes

Or, just do that…

Sorry, couldn’t disagree more with both Wikipedia article excusing a system for succumbing to the effects of soft data or with your implication in posting it.

Being able to anticipate problems and developing responses to them is what separates the coding men from the boys.

There’s never an excuse for data imploding its program.

Cosmic rays are effecting Roon?

1 Like

Yes, that’s a thing. But it’s not the only source of such errors.

Years ago, I had intermittent stability issues with a computer at work. Turned out that one bit in one of the memory modules was stuck at “1”. Read any piece of code into that location in memory, and you had a 50% chance that what was supposed to be a “0” would silently turn into a “1”.

I eventually tracked this down when a “>” in a Perl program mysteriously turned into a “?”, without any intervention on my part.

(And, for the cognoscenti, the typical NUC/Nucleus that Roon runs on doesn’t use ECC RAM.)

1 Like

As one who had to track down many mainframe software bugs over the years (not in my code, of course :slightly_smiling_face:) the one you talk about must have beem a real bitch.

As Roon users, of course we would like to see Roon become a perfect platform that never fails and never has issues. We can make threads in the Support forum and make suggestions in the Feature Request forum, then sit back until someone fixes the problem or implements the requested feature. Personally, I prefer to be proactive and fix what I can so my system works now.

I brought up this story because it seems rather apropos of @Jim_F’s original post: a general lack of stability with no obvious cause and no apparent pattern (different programs crashing or misbehaving at seemingly random times).

When I finally saw the altered Perl file, my first thought was … “cosmic rays.” Fortunately, I had the perspicacity to run a memory check and was relieved when one of the RAM modules failed, with a bit stuck in the “1” position — exactly as one would have predicted from “>” turning into “?”.

Some programming mistakes — like memory leaks — can be worked-around by rebooting frequently. But I haven’t seen any evidence of memory leaks in Roon (yeah, I’m the kind of guy who checks).

The sort of issue I ran into? Not so much …

There was a memory leak issue years ago iirc. Roon is pretty good at fixing bugs once they can be replicated. It’s the sporadic non-repeatable problems that create angst for users and developers alike. If you can reliably reproduce a bug in Roon then report it in the Support section as there is a good chance it can be squashed.

Hmm, I always believed that some of Roon’s current reboot needs, or the odd things that sometimes happen with Roon Radio, were caused by memory leaks.

@Jacques_Distler, I was musing about your physical memory bug over dinner. It would have been impossible to trace on a big main frame system what with dynamic address translation, relocatable code, and multi-tasking.

OTOH, those big systems have hardware error checking built in, they have to.

So either you talk of a time before these things or (more probably) a system that didn’t have these embellishments?