Is anyone else suddenly experiencing dropouts and halts

I did say I used Fixed for all my servers and machines, some people have reservations about doing this and if you mess it up can render the machine inaccessible without a screen and keyboard.

Networking is not a thing all users will be familiar with and messing with router settings to get excluded address space for static addresses is also not the normal thing for users to go messing with. If you have the expertise to do so good for you.

Most users are probably not rolling with a Linux core either :wink:

Actually you said that you used “reserved DHCP addresses for all my fixed machines”. In my experience this can cause issues with Linux based machines that run NetworkManager to render the IP address. As ROCK is also an implementation of Linux then there is a possibility that it is also impacted with the memory segment faults that is causing issues on Ubuntu. There are lots of posts on this forum recently reporting similar symptoms of disconnects with Linux based platforms. Simply changing to a static address rather than using DHCP or DHCP reserved addresses is a quick and easy way to rule this out as a potential root cause.

I was having the same symptoms with my NUC / Roon install… I’m running the Roon binary install on Ubuntu… I ended up rebooting all network appliances except my switch… And no luck. Then I rebooted my switch and it started to well again. Strange that it was a layer 2 issue… But it was…

to both Robem and Johnny:

  1. There is some confusion here. Most ISPs charge for having an static EXENAL address. But you can assign your computer/Roon server a static IP address within your home router’s range. In ROCK its int he web GUI. For your mac, for example, its in the network control panel. Xfinity has nothing to do with it

  2. To Robem. I cannot see how having DHCP vs static would have the slightest impact. A DHCP lease is typically days to weeks and while assigned works no differently for routing than a static one. So basically disagree.

To all - I have mostly isolated my issue and it has to do with grouped zones as I speculated above. I cannot say if its network congestionl processor congestion or flaky endpoints - but with the gorupign gone its pretty much a non issue now. This is not a totally good answer, but eliminates many paths of investigation. I did get a significant change when i restarted the server several times in a contorlled manner, rather than letting mother natures power outages crash it with no journaling.


Hmm. Got to admit that I don’t think I have much (if ever) included rebooting my switch in my “network got glitchy, reboot it before I contact support” playbook. Assume you are running managed switches - do you mind if I ask what flavor/brand of network gear you are running? I’m going to try this too. What with Zoom classes, work, music, etc - I’ve found that I have to stay up late to do a modem/router/AP reboot cycle; but now at least I’ll give it a shot to include switches in the reboot cycle too. Thanks for suggestion.

Just a question for all here… Typically I assign fixed IPs within my Unifi controller, vs. assigning one within the device / telling it not to bother with DHCP. I have done that historically because it means I don’t have to worry as much about IP conflicts / documenting which device has what IP address. But now I’m thinking that that means that my ROCK (or other server) is still using DHCP, it’s just that it always gets the same address. Not sure that actually reduces the number of DHCP pings, which sounds like it’s the goal. However, if there are long leases, not sure why there would be frequent DHCP pings.

Are you saying that I should assign the address within the ROCK GUI, and that if I assign a fixed address at the Unifi controller level I’m not actually getting the benefit you’re describing?


The worse thing you can do, unless you also set that address as reserved in your router or exclude that address from DHCP in your router.

Really, make it easy on yourself and jusr reserve the address in your router software. In spite of what sticklers might want, I’ve done that for years without any problems.

Ok, I apologize that I took us off topic, especially to the OP; consider my sub-topic resolved; I am using reserved IP addresses for my ROCK within my DHCP controller as suggested.

However, I too continue to suffer from track pause/skip, both on Tidal and on internal FLACs from NAS. Am going to copy my music library to a USB drive and connect it directly to the ROCK and see if that resolves things. Headed back to my own thread, with thanks.

@Johnny_Ooooops - your setup, using reserved IP addresses in your router continues to utilize the DHCP protocol. With some flavors of Linux we have seen that there is a conflict with the NetworkManager service and Roon which causes process crashes when DHCP4 polling occurs. It is really simple to enter that same reserved IP address as a static address in the Rock GUI and see if that resolves your stability issues.

@Just_Me the NetworkManager still performs DHCP4 polling when using a reserved IP address. Please see this thread for detailed troubleshooting.

1 Like

Are you referring to me as a stickler? Personal attacks are not needed and offer no value to this thread at all. Are you running Roon Server on a Linux platform? Can you offer first hand experience with this issue? Or is this an excuse to increase your post count? I think the following quote from the post I linked above infers that you are running Windows on your core because you had nothing but trouble with RoonServer.

“Don’t know if all the problems in this thread are occurring to folks who are running RoonServer, but I had nothing but trouble with RoonServer.“

NetworkManager is a buggy disaster, there are extensive complaints about it on forums, especially with Ubuntu 20.04.1. I’ve disabled it, doesn’t serve any useful purpose on a small dedicated server with a fixed set of active network interfaces.

Easy, big fella. Using the description of ‘stickler’ hardly qualifies as an ad hominem attack.

Not talking about you any more than anyone else. Other people, in the past, have counseled using static addresses on devices and excluding them from DHCP rather than reserving an address in the router software, and for most people in a home environment, that is unnecessary.

What was that about “personal attacks”? If you look at my profile you’ll see that I don’t need to increase my post count by one or one thousand.

The word you want is ‘implies’.

Just FYI - I have my local music library local on SSD, so remote access to music files was not my issue (except, when using Tidal of course). The fact that ungrouping zones fixed it suggests (for a bunch of reasons you all can infer) that disk access is not the issue.

Its too bad that the ROCK or Roon web gui doesn’t have basic performance data so we could see CPU utilization, buffer over/under runs, etc - basic stuff that could eliminate all this guessing.

Maybe it does exist. If so its not well communicated.

Le us know if your problem turns out to be related to where your music is stored. In my case i’m wondering if changing the buffer size might help, although that would also create larger inter-track delays. No free lunch :frowning:

Well obviously there have been instances recently where this statement has proven incorrect with Roon on certain platforms.

I’ve been running Roon for 3 x zones for almost 2 x years. Only once have I had to recycle any network gear. The fact it was my layer 2 switch was surprising. My GF noticed Netflix movies where running a lower adaptive bit rate / resolution and even noticed a buffer or two. This is very rare for us… I used my managed app to reboot my Amplifi router and AP’s… Neither of those devices rebooting fixed it. Then I resorted to something I never do… This being cycling my layer 2 switch. Then boom… Netflix and Roon where rocking. I use a cheap Netgear managed switch… I plan to get an Aruba fan-less managed switch soon. For my router / APs I use AMPLIFI mesh kit. I also have all network gear on UPS’. It been an extremely rock solid solution. I used to run Roon core bare metal install on my NUC, however, I moved to a binary install for I run LXD containers on my NUC Ubuntu host also.

Thanks. I tried, setting the exact same settings in fixed IP as were shown in the DHCP tab, and managed to make my ROCK unreachable :slight_smile: I luckily had a USB keyboard nearby and managed to <RETURN>networkreset<RETURN> my way out of trouble without bricking my ROCK. I’m so glad the ROCK has that enabled; I’ve screwed up a couple other times in my network admin dilletantism and needed to get out of trouble but those devices had to be factory reset. This is much better. Will try again later.

It’s a common mistake (I’ve made it) to set a fixed IP address in the device, rather than as a fixed MAC address->IP address in the router’s DHCP tables. If the device has a fixed IP in its internal network configuration, but the network itself changes, maybe because of a new router, what the device uses as its IP address and what the network thinks that device’s IP address is can disagree, with bad consequences as you describe.

1 Like

I’ll report back if/when i hear about the logs. As this drifts into DHCP land i’m signing off…

Actually I use both setting and have no issues using either singularly or together…I like to keep the fixed ones on the reserved list so I have them in sync and can list them easily.