Dropouts with an i5 Nuc and RPi [resolved, turned of fbonded ethernet on NAS]

Hello @support
Just updated to latest build of 1.3 and have intermittent audio dropouts and looses connectivity to CORE as well intermittently. No other changes have been made to my network and devices. Same devices as 1.2 version I had previously. Happens on any file, including tidal files.
Seems similar to others who posted about drop outs and losing connection between controller and CORE - which happens to me too.

Core: Intel i5 nuc, 256gb dsd, 8gb ram, Ubuntu Linux v16.04, latest updates, wifi disabled.
Bridge: Raspberry pi3, wifi disabled, USB to bda3 DAC
Storage: buffalo NAS , 12tb, 1.5tb of music, dual gigabit from NAS to gigabit Ethernet backbone.
No wifi in signal, but wifi in house for iPad Roon Controller


Tried music files on locally mounted USB drive to the NUC to see if there’s something network related between the NAS and the CORE. No difference. Same drop out issue. My library size is 18K tracks, 2007 albums. Hope this helps.

@support team - wondering if you’re seeing this drop out issue across other CORE users on Linux or Windows? My buddy who upgraded on Windows 7 has not told me of this issue. Can you provide us with a status?
Please let me know how I can help. I can send logs, etc.


Hi @Ian_Drachman – sorry to keep you waiting on this one. We haven’t heard widespread reports of dropouts with the latest builds. We have seen some new reports, and we’ve seen a number of reports of less dropouts, which is probably due to some performance improvements in 1.3.

Since the vast majority of dropouts issues are environmental, I wanted to get a little more information about your network as described here? In particular it would be good to know what network hardware is used, and how everything connects.

I noticed you said you’re using “dual gigabit” too – I assume that means a bonded network interface? Is it possible to test with that switched off?

Can you also check Settings > Library and confirm that audio analysis has completed?

Finally, you may want to give this guide a read, as it’s pretty detailed about the underlying causes for audio dropouts. We can absolutely look into this further for you, but I want to rule out basics first.


this is @ian_Drachman, i’m using the same network configuration as before. no changes since upgrading to version 1.3. So, if no changes, what’s different about 1.3 that could cause this? Any config changes that I could potentially look at?

As stated in my original note:
Core: Intel i5NUC, SSD 256GB, 8GB ram, Ubuntu 16.04 (latest updates), wifi disabled, all ethernet gigabit, managed and unmanaged switches (Netgear), no VLANs in use or QOS prioritization being used.
Raspberry Pi3 - with Bridge being used to USB to Bryston BDA3 (new Audioquest USB cable), wifi disabled, all ethernet gigabit.
Buffalo 12TB NAS, dual NIC cards, mirrored, 1.5TB of music, 18K tracks, 2K albums,
CORE finished all processing.
What other information other than what I’ve provided do you need from me to help troubleshoot the intermittent dropouts?
Ian D

Hi Mike,
I’m using Netgear GS108E, GS108 and GS 24 (unmanaged) gigabit switches. Yes, I can decouple the bonded network interface on the Buffalo NAS, effectively switching it off.

Library analysis completed when I initially upgraded and rechecked this again that its not running.
I read through the drop out guide again and as mentioned before, no hardware is limiting performance and no network changes have been made. The hardware I’m using is what Eric had recommended (NUC i5, and Pi). The only difference is upgrade to v1.3.

I also mounted a USB drive (with subset of songs I have on NAS) directly to my NUC and the same dropouts occurred. So, its probably not the network between the NAS and NUC.

But, i’ll give it a try when bonded is turned off and revert. It will be a couple of days for me to get around to this since I’m travelling.

Any other suggestions? I’ll try those in serial.


Hi Mike,
Why am I seeing this error in the log? It seems to correspond to when I notice dropouts.

Welcome to Ubuntu 16.10 (GNU/Linux 4.8.0-38-generic x86_64)
ian@Rooncore:/var/roon/RoonServer/Logs$ tail RoonServer_log.txt
02/23 09:21:32 Warn: Error in web request https://push.roonlabs.com/push/1/conne ct: NetworkError (The remote server returned an error: (502) Bad Gateway.)
02/23 09:21:32 Trace: [push] request to manager failed
02/23 09:21:32 Trace: [push] retrying connection in 25935957ms


Hey @Ian_Drachman,

That’s related to some incomplete functionality on our server, and is unrelated to this issue (and completely harmless).

Great, let us know and if it makes no difference we can dig into this further.

@Eric and I are going to discuss with the team today. We’ll let you know if we have any additional feedback.

I noticed that two of the switches you mentioned appear to be managed. I know you said you have it running unmanaged, but it might be worth confirming that.

Moreover, it might be an interesting test to see if things behave better with the simplest possible network – a DHCP router, the NUC (w USB storage), and the RPi. If that behaves, at least we’ll know the switches are where things are going awry.

Let me know how that goes, and we’ll keep at it until this is working for you. Thanks!

1 Like

Hi Eric/team -
Switches are operating as a pass through, no VLANs setup, all are on a single default VLAN 1. They have always been setup this way - with v1.2 operating without dropouts.

On your suggestion I did run the NUC with local USB storage and the RPi. Same issue with dropouts. I even tried two other end points - Bluesound Pulse and a PC on the network (PC speakers) and same exact issue occurs. Maybe a clean install of v1.3 is in order? If you want me to pursue

Maybe v1.3 is more critical/less tolerant of a network than v1.2 and therefore more revealing of issues during playback?

Hey @Ian_Drachman – thanks for the details.

In general, we’re seeing 1.3 being more tolerant with less dropouts, but there have been a lot of changes and bug fixes, and it’s always possible that changes can affect certain network configurations differently.

In the vast majority of cases, dropouts are caused by something environmental, and that could be related to a change in the app interacting poorly with something your environment, a problem in your install or database, hardware starting to fail, or the network configuration.

Ok, that’s a good test to rule out the NAS. Was this test run with the exact same network configuration, or were there any changes on that side too?

Here are a few more things I would try if you haven’t already, in order to modulate the issue:

  • Try the simple network test I mentioned above - router, two cables, endpoint, Core (to eliminate network configuration or hardware issues)
  • Try the same network, endpoint, etc, but use a laptop as the Core (to eliminate Core configuration, Core hardware, or performance issues)
  • Try with a fresh database by moving your current database aside and trying with a fresh database (database location info is here – a fresh database will eliminate any issues with your Roon install or database)

Again, these kinds of issues tend to be some of the most frustrating, because there’s no simple way to know what’s going on. Let me know how you get on with the tests above, and we’ll figure this out.

Thanks @Ian_Drachman!

Ok Mike. Here’s the latest:
Eliminated the bonded gig on the NAS

Please keep in mind all of this equipment and configuration worked without issue before. No dropouts, but some songs skipped, even from TIDAL.

Tested this configuration - no drop outs - after 10 minutes of playing
Tried Bluesound Pulse - no drop outs - after 30 minutes of playing

Will continue to test, I’ll send an update after the weekend.


1 Like

No dropouts at all throughout the weekend. I’m leaving well enough alone, no more testing/changes.
Thank you for your help and responsiveness. Onto the music.
Thanks Mike!

1 Like

As a further data element: I had similar problems after the 1.3 upgrade. I also have two 1gig bonded network adapters on my NAS and switch. In my case I found that the ‘flow control’ option on my switch was set ‘off’ and needed to be set ‘on’. After I set ‘flow control’ ‘on’ on my switch my problems went away. I am still using the bonded adapters. YMMV…

Out of curiosity, do you know the specifics of the “bonded ethernet” implementation on your NAS? As far as I know, there’s no way to do proper link aggregation without (managed) switch support for LACP or some vendor-specific protocol.

If it is me you were querying, my switch is a Netgear GS724Tv4 quasi-managed switch and it does support LACP. I’ve tested the throughput of my bonded ethernet configuration and I am getting just under 2 gig out of the NAS - assuming I pile on the loads so requests from multiple sources hit the box.