Roon loses control regularly, requires restart from IP address (ref#GR2R7P)

Support
1

What’s happening?

· I am experiencing freezes or crashes

Describe the issue

Roon appears to "lose control" on a regular basis. Impossible to run in a stable fashion for several days in row. Requires restarting from the IP address.

Describe your network setup

Optical fiber internet connected to cable co. proprietary router then to Linksys Velop mesh network. Roon nucleus is wired by CAT6 cable to one of the mesh routers

2

This could be a cause of your issue. Roon works a lot better if using a wired ethernet connection to the router handling the ISP connection.

If you have Wifi involved - even if just between Mesh WiFi nodes, then Wifi congestion can limit the bandwidth (probably not an issue) and cause latency issues - especially if using WiFi connected endpoints as well.

If you can (Nucleus not connected by USB to a DAC), could you try moving your Nucleus so that You can connect it to the primary router (or the Linksys Mesh node that is connected to it by ethernet) so that no WiFi link is involved in the route between the nucleus and the ISP connection. See if this improves the situation.

If you can’t move the Nucleus, you may be able to achieve the same thing by temporarily using a long ethernet cable to connect the Nucleus to the primary router (as I’ve said on many occaisions on this forum, I keep a 50m CAT6 cable for this purpose).

WiFi mesh systems have two issues that can affect Roon use:

  1. Unless care is taken, they can dramatically increase the amount of data being sent over WiFi - which can cause contension issues between devices as well as reducing the data rate available to any one device. Just as a case in point, imagine a three node WiFi mesh network with nodes A, B and C connected using a WiFi backhaul (the connection between Nodes). Node A is connected by wire to the ISP connection, Node B is connected by wire to a Roon Server and Node C is connected by WiFi to an endpoint. Now, when streaming from Tidal/Qobuz, the stream data has to go from the internet to the Roon Server (Wifi from Node A to Node B), and then from the Roon Server to the Roon Endpoint (via Node C - which means WiFi from Node B to Node C and then Wifi from Node C to the endpoint). The net result is that the same stream is transmitted over the same wifi network 3 times and each of these interfere with each other and cause latency issues. By contrast, with a single node WiFi network, the audio data stream is only transmitted over WiFi once - to the endpoint - and so no WiFi contension occurs (at least with the audio streams - there may still be contension with other WiFi activity).
  2. Mesh systems can cause significant spikes in latency when a device roams from one Mesh node to another (handoff). This will not be happening to your Nucleus, because it is connected by ethernet to a mesh node, but it may be happening to any WiFi connected endpoints. Most mesh systems allow you to permenantly associate a device with a particular node. This should be done for all non-mobile devices in order to avoid handoffs.
2 Likes
3

This makes a lot of sense, comparing my current setup to the previous setup in a much smaller house where the nucleus was connected via fewer Linksys mesh units (one connected to the ISP and the other via WiFi connected to the nucleus). That was quite a bit more stable. Can try to troubleshoot with 30m cable, but ultimately there won’t be a simple solution as the listening room with the nucleus is on a different floor than the ISP. thanks much.

4

I have my Nucleus connected by ethernet cable to my router in our main bedroom downstairs. I use WIFI from my router to a Raspberry Pi4 in my upstairs music listening room. The RPi4 is connected to my DAC/preamp by USB. It is very stable and never misses a beat (pun intended).

5

Unless you have the Nucleus directly connected to an endpoint device by USB and HDMI, the Nucleus can go anywhere in the house.

If you do have your Nucleus connected directly to an endpoint device by USB, you can add a small, cheap Roon Ready (or equivalent) device such as a FIIO SR11 or a Raspberry Pi running Ropieee or DietPi or RaspberryOs and many other linux variants and connect that to your Endpoint device by USB instead.

If your Nucleus is connected to an Endpoint device by HDMI, things are not quite as simple. The Raspberry Pi solution would still work up to a point (it would only do stereo audio because of the limitations of the Pi HDMI). I believe, however, that a cheap, possibly second hand, Intel/Asus NUC (no need to be high powered) running Roon Bridge (under a linux distro or Windows) would be able to convey multi channel audio to an AVR over HDMI (you could even use a ROCK system or even another Nucleus for this purpose but that would make things more complicated because the ROCK system/Nucleus would also be visible on the network as a Roon Server - but one that you never want to connect to).

Anyway. The first thing to do is to try to elliminate WiFi as a cause of the issue using a long ethernet cable (or two). Then you will know whether your Mesh network (or another aspect of WiFi perfromance) is the cause of the issue or not and you will be able to think about solutions in a more informed manner.

6

Will try that. Yeah, the nucleus is currently connected in the listening room via USB to a DAC and then to amplifier, so I would need to use something like the Raspberry Pi you both mentioned. Need to give this some thought and then make some changes. Too frustrating otherwise. Thanks again.

1 Like
7

As I said, before spending £60 pounds or more (in the UK - probably between $60 and $80 in the US), use the long cable to check that it solves the issue.

If just using as a Roon endpoint device, there is no need to go overboard on the Raspberry Pi spec. A RPi4 with 2GByte of RAM is more than enough.

Avoid the Pi Zeros and Pico’s because they only connect via WiFi. An RPi4 with a wired connection to a Mesh node will give you a bettter experience than an RPi (of any type) connected to the same Mesh node by WiFi.

An RPi3 is not quite such a good option as an RPi4 because it shares bus bandwidth between the ethernet adaptor and USB whereas the RPi4 does not - and the RPi3 is not significantly cheaper - at least here in the UK. Having said that, I’m sure that there are plenty of people quite happy with an RPi3.

An RPi5 is complete overkill for this application and is significantly more expensive. Of course, if you have one lying around otherwise unused, it would be fine to use it.

Don’t forget to add a case. a flirc case (metal heatsink and passive cooling built in) is a popular choice. Personally, in an almost identical situation (no HATs, just a USB connected DAC), I use an Argon One V2 case because I like the look. This case has a built in fan but it does not use it under normal circumstances. The passive cooling is pretty good. I have to say, though, that when the fan does turn on, it is quite noisy. The temperature at which the fan turns on is controllable under Raspberry OS or DietPi/Debian. I’m not sure about Ropieee though.

1 Like
8

Hi @Mark_Ellenbogen,
Thanks for reaching out to us about this issue. I agree with what @Wade_Oram said. Please try his suggestions and let us know whether you are still having any issues.

9

Still having issues. I physically moved the Nucleus from the listening room to the floor where it has a direct wired connection to the ISP. Still stopping and starting without explanation. “Losing control of the audio devices,” freezing. Not playing certain tracks and skipping tracks. Now, the speakers in this area are not the wired ones of the listening room, but rather 4 Sonos speakers connected by WiFi. Is there possibly a problem with those that is affecting the playback?

10

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.