Plagued with dropouts for years (ref#9CN9S8)

Support
41

Hi @Geoff_Bishop,

Thanks for your extended patience here - the Qobuz playback issue has largely been resolved, but there may be a few lingering tracks that cause you issues.

Qobuz aside, a fresh Nucleus diagnostic report has shown the following:

The Naim Mu-so (Kitchen, 192.168.0.224) is the root cause of grouped playback failures

The single most important pattern in the logs: the grouped zone Music Room + Kitchen is destroyed and recreated 35+ times on April 7 alone, every 10–30 minutes. Each cycle follows an identical sequence:

  1. The Mu-so at 192.168.0.224 drops off the network (No route to host or port unreachable)
  2. The grouped zone is torn down
  3. Roon rebuilds the zone with just the Uniti Star, then tries to add the Mu-so back
  4. Playback resumes briefly, then the cycle repeats
This is not a Roon server problem, the server itself is healthy. The Mu-so is periodically becoming unreachable on the network.

The [rnet/RnetJsonClient] failed to connect No route to host warnings consistently reference 192.168.0.224 (the Mu-so’s address), and they appear immediately before zone destructions. This Rnet connection is how Roon communicates device state — when it fails, Roon tears down the zone.

Question for you - What switch port does the Mu-so plug into, and what switch? The Mu-so’s network interface or the switch port feeding it may be periodically going down/coming back (EEE/green-mode link drop, faulty cable, or a switch port auto-negotiation issue).

With that:

  • Try a different Ethernet port on the switch
  • Try a different Ethernet cable to the Mu-so
  • Log into the Mu-so's web interface and check if it shows any link/network errors
  • Consider assigning the Mu-so a static IP in the router to rule out DHCP lease churn

Alongside this, we also found that the DESKTOP zone (on a Windows PC at 192.168.0.249) is being created and destroyed hundreds of times per day, every day. On April 15 alone: 1,044 create/destroy cycles.

This is almost certainly a PC with Roon installed that goes into sleep/screensaver/power-saving mode repeatedly. While this is not a direct cause of audio dropouts on the Naim endpoints, it generates continuous zone management traffic on the Nucleus, thousands of transport layer events per day, and contributes to both memory pressure and GC load. This is a significant background stressor that should be eliminated.

Thanks, Geoff! :raising_hands:

1 Like
42

Benjamin, thanks for your investigation of this situation.

Firstly, in the DESKTOP zone, I have now taken the Bluesound Pulse Mini 2i off the network (disabled it in Roon and removed the cable connection). It was only ever used for PC audio (I never listened to streamed music in my Office) and this can be adequately covered by connection to the PC audio output. Obviously the PC itself remains as a Roon endpoint on my network but I rarely open the Roon app on my PC (mainly when doing backups), so the PC sleeping problem should disappear. Or should I Disable the PC as an endpoint and only Enable it when for the occasions I need it?

I logged into the Mu-so’s web interface and the only red flag was for Apple Airplay Authentication “Unable to find auth. chip!”. I never use Airplay and it is not enabled on any of my endpoints, so I assume this “failure” is irrelevant.

The Mu-so is connected to Network Switch 1 (Netgear GS305), which is adjacent to the Router. I have tested the cable from the Router to the switch and from the switch to the Mu-so and no problems were detected. There are no other network connections to this switch. I have been switching around the two cables among the network switch ports but have noticed no difference in performance.

The Music Room and Kitchen endpoints remain Ungrouped.

I have turned off DCHP on the Mu-so

Having done all the above, I’m still getting a few dropouts both during both streamed and local file playing, but nowhere near as many as before.

Geoff

43

Still getting some dropouts but only on the kitchen endpoint ( but listening period on the kitchen endpoint is usually longer than in the music room so maybe it’s a question of time)

44

Solution? Rather late in the day, I’ve discovered that, although my Virgin Media hub router has four, 1GB Ethernet ports, there is one labelled 2.5 Gbps which is intended for gaming and other demanding uses. So I moved my Ethernet cable (the one connected to network switch 1 and from there to my Naim Mu-so 2 in the kitchen) to this port and, hey presto, no more dropouts, either when streaming or playing local files.. This was fine for three days but, tonight, I had one short dropout while streaming from Qobuz. I’m now considering moving the network cable connecting to Network switch 2 (Roon Nucleus One and Naim Uniti Star) from the router to Network switch 1. Will let you know what transpires. Incidentally, although it might be my imagination, the SQ seems to have improved. Whether this result from my port switches or from the latest Roon update, who knows?

45

Well it seems to have worked. All my networked devices are now connected to the internet via the 2.5 Gbps port on my router. I’ve had no dropouts at all. So is this demonstrating that the Roon system needs this level of connection to work properly? Is this included in the system requirements list on the Roon site? If,not, should it be? I’m definitely convinced that my SQ has improved since I made these changes.

1 Like
46

Not really. I have 1 Gbps in a healthy-but-nothing-special network, and have not had a dropout in 5 years. Music streaming needs, even at 192/24 PCM, 1/100 of 1 Gbps. (Depending on the number of parallel streams of course). Good latency is important (but only to the extent that one expects on a healthy LAN).

With reasonable wifi, endpoints can be fine on wifi. For the server, Ethernet is better but very good wifi can work. (If it doesn’t, look there first)

Anyone whose network conforms to this, should be fine:

1 Like
47

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