Netgear Orbi, ROCK and endpoints hardwired via switch to the router
Connected Audio Devices
Wiim Pro via optical into KEF LS50W (not connected to network)
Number of Tracks in Library
c. 5,000 I think
Description of Issue
I’ve been having this issue where my music will just stop periodically, seems to be happening more and more often. My Roon remotes will also often lose connection to the core. I’ve been trying to use Russell V’s TV:Remote app on Apple TV but this also loses connection very frequently and seems to make the music stop even more often than it does without this app running.
Having looked at the logs what seems to be happening is that the core falls off the network every few minutes, sometimes it reconnects fast enough to not stop the music playing, but if this goes a bit longer then the playback stops. During the time it’s fallen off the network I can’t see it via SMB on my Mac either.
This is what happened when I watched to see what was happening. I tried to start playback as close to 15:00:00 as possible but had to wait until about 15:00:15 for it to come back on the network. After that it came and went as follows:
15:00:00 - not connected to Roon controller on Mac
15:00:15 - connected, hit play
15:00:45 - seemed to lose connection but still playing
15:01:20 - connected to Mac again, playback continues
15:01:40 - dropped off again, still playing
15:02:15 - back on Mac, playback continues
15:03:40 - dropped again, still playing
15:04:13 - back on again
15:07:20 - music died
You can’t assign a static IP address through the router, that’s a reserved IP address which is very different. A static IP address can only be configured on the device itself. This is important to understand because a reserved IP address still uses the DHCP client on the host whereas a static eliminates the use of the DHCP client.
Ok, so maybe my terminology is off. With my question I’m just trying to figure out if the OP maybe assigned a static IP from within the DHCP address range.
Of course I may be wrong, but this seems to suggest that there is a network issue on the NUC. Perhaps you could run a “ping” from a terminal on Mac to the NUC without having any music playing? Just to see if you have any package loss.
Have you tried disabling IGMP Proxying? According to this thread, and a number of others, IGMP Proxying on the Netgear Orbi can cause network issues when using Roon.
I’ve just done this now while the Roon remote was showing as disconnected:
PING 192.168.1.3 (192.168.1.3): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=11603.553 ms
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
64 bytes from 192.168.1.3: icmp_seq=6 ttl=64 time=13504.692 ms
64 bytes from 192.168.1.3: icmp_seq=7 ttl=64 time=13821.216 ms
64 bytes from 192.168.1.3: icmp_seq=8 ttl=64 time=13691.500 ms
Request timeout for icmp_seq 22
64 bytes from 192.168.1.3: icmp_seq=10 ttl=64 time=13577.615 ms
64 bytes from 192.168.1.3: icmp_seq=14 ttl=64 time=10401.978 ms
64 bytes from 192.168.1.3: icmp_seq=15 ttl=64 time=10675.264 ms
Request timeout for icmp_seq 26
64 bytes from 192.168.1.3: icmp_seq=16 ttl=64 time=11150.559 ms
Request timeout for icmp_seq 28
64 bytes from 192.168.1.3: icmp_seq=17 ttl=64 time=12234.869 ms
Request timeout for icmp_seq 30
Request timeout for icmp_seq 31
64 bytes from 192.168.1.3: icmp_seq=18 ttl=64 time=14227.092 ms
64 bytes from 192.168.1.3: icmp_seq=19 ttl=64 time=14964.049 ms
Request timeout for icmp_seq 34
64 bytes from 192.168.1.3: icmp_seq=25 ttl=64 time=10873.231 ms
64 bytes from 192.168.1.3: icmp_seq=26 ttl=64 time=10586.000 ms
64 bytes from 192.168.1.3: icmp_seq=27 ttl=64 time=10145.799 ms
64 bytes from 192.168.1.3: icmp_seq=28 ttl=64 time=9354.951 ms
Request timeout for icmp_seq 39
64 bytes from 192.168.1.3: icmp_seq=32 ttl=64 time=8857.944 ms
Request timeout for icmp_seq 41
Request timeout for icmp_seq 42
Request timeout for icmp_seq 43
Request timeout for icmp_seq 44
64 bytes from 192.168.1.3: icmp_seq=34 ttl=64 time=11720.026 ms
Request timeout for icmp_seq 46
64 bytes from 192.168.1.3: icmp_seq=35 ttl=64 time=12355.767 ms
64 bytes from 192.168.1.3: icmp_seq=36 ttl=64 time=11990.506 ms
64 bytes from 192.168.1.3: icmp_seq=37 ttl=64 time=11069.715 ms
64 bytes from 192.168.1.3: icmp_seq=38 ttl=64 time=12947.110 ms
64 bytes from 192.168.1.3: icmp_seq=39 ttl=64 time=12970.917 ms
Request timeout for icmp_seq 52
Request timeout for icmp_seq 53
64 bytes from 192.168.1.3: icmp_seq=41 ttl=64 time=13133.355 ms
64 bytes from 192.168.1.3: icmp_seq=45 ttl=64 time=10200.715 ms
64 bytes from 192.168.1.3: icmp_seq=46 ttl=64 time=10959.926 ms
64 bytes from 192.168.1.3: icmp_seq=47 ttl=64 time=10575.790 ms
64 bytes from 192.168.1.3: icmp_seq=48 ttl=64 time=9947.029 ms
64 bytes from 192.168.1.3: icmp_seq=49 ttl=64 time=9638.256 ms
64 bytes from 192.168.1.3: icmp_seq=50 ttl=64 time=9860.681 ms
64 bytes from 192.168.1.3: icmp_seq=51 ttl=64 time=10608.952 ms
Request timeout for icmp_seq 62
64 bytes from 192.168.1.3: icmp_seq=53 ttl=64 time=10362.412 ms
64 bytes from 192.168.1.3: icmp_seq=54 ttl=64 time=10002.108 ms
64 bytes from 192.168.1.3: icmp_seq=56 ttl=64 time=9757.786 ms
64 bytes from 192.168.1.3: icmp_seq=58 ttl=64 time=8436.631 ms
Request timeout for icmp_seq 67
64 bytes from 192.168.1.3: icmp_seq=59 ttl=64 time=9178.682 ms
64 bytes from 192.168.1.3: icmp_seq=61 ttl=64 time=8562.791 ms
64 bytes from 192.168.1.3: icmp_seq=62 ttl=64 time=7616.400 ms
64 bytes from 192.168.1.3: icmp_seq=63 ttl=64 time=6748.704 ms
64 bytes from 192.168.1.3: icmp_seq=64 ttl=64 time=5804.624 ms
64 bytes from 192.168.1.3: icmp_seq=65 ttl=64 time=4912.428 ms
64 bytes from 192.168.1.3: icmp_seq=66 ttl=64 time=3980.527 ms
64 bytes from 192.168.1.3: icmp_seq=67 ttl=64 time=3025.445 ms
64 bytes from 192.168.1.3: icmp_seq=68 ttl=64 time=2076.972 ms
64 bytes from 192.168.1.3: icmp_seq=69 ttl=64 time=1122.942 ms
64 bytes from 192.168.1.3: icmp_seq=70 ttl=64 time=223.263 ms
64 bytes from 192.168.1.3: icmp_seq=71 ttl=64 time=4.961 ms
64 bytes from 192.168.1.3: icmp_seq=72 ttl=64 time=4.839 ms
64 bytes from 192.168.1.3: icmp_seq=73 ttl=64 time=5.182 ms
64 bytes from 192.168.1.3: icmp_seq=74 ttl=64 time=5.521 ms
64 bytes from 192.168.1.3: icmp_seq=75 ttl=64 time=6.932 ms
As you can see towards the end it starts connecting sporadically and slowly, then from seq71 onwards its back to normal. This corresponds with when the Roon remote looks like its connected again on my Mac
Wow! Definitely a network issue I would say. I would even consider the 4 and 5 ms ping time to be long for a LAN. Question is: where does the issue come from?
Do you have a single switch connected to the router or are there multiple, switches involved? Could it be that you have loops in your network? E.g. router is connected to switch 1 and switch 2, but switch 1 is connected directly to switch 2. Or, if just a router and a single switch, 2 UTP cables between the router and the switch? Unless of course you have smart switches with port aggregation.
If your network setup is ok, I would try to isolate the problem by repeating the ping between various sets of 2 devices. For example between the Mac and the WiimPro, the Mac and the AppleTV, but also if possible from another computer to these devices.
If these pings are ok, chances are there is an issue with the NIC on the NUC. If these are failing, then potentially you switch or router may be failing.