I’ve been running Roon on a dedicated little Windows 10 machine for a couple of months now. Roon really is the best thing since pockets, and nothing else even comes close. I’ve noticed, however, that playback will randomly stop–not often but occasionally enough for me to wonder because the server should have more than enough resources available.
Intel i5-7500T CPU at 2.7GHz
8GB memory
128GB SSD system volume (internal SATA)
2TB SSD storage volume (internal SATA)
It’s connected via 1GB wired Ethernet connection to the router
I’ve removed every app possible that comes with Windows that’s unnecessary.
I’ve disabled some obviously unnecessary services.
I’m not running HQPlayer or any intermediary processing software
I do have antivirus software on the machine, but non-essential elements (mail scanning, etc.) are disabled because all mail functionality has been removed from the machine.
Output is USB to a Schiit Bifrost Multibit (which is an absolutely brilliant price performer by the way)
Something could lurk in the Windows Task Scheduler because Windows includes an ocean of things there it likes to do. I haven’t messed with those, though.
So . . . this machine should have power to spare for Roon so that it never has to compete with anything so demanding that it would have to pause. Am I missing a configuration option?
Can you provide some more information regarding your network here? What is the model/manufacturer of your router and any switches/range extenders/powerline adapters/ect?
You mentioned that you have antivirus on the machine, can you please add both Roon.exe and RAATServer.exe as exceptions to it? I would also add these exceptions to your Windows Firewall using these instructions just to be safe, and you can find Roon.exe and RAATServer.exe in the Database Location/Applications path.
Do you notice any pattern to the issue occurring? Does it only occur with one type of file format? Higher sample rates? Longer tracks? ect.
The machine is directly connected to an Asus RT-AC66U_B1 router. There are no switches/range extenders/powerline adapters/etc. When music is playing, the machine is not sharing the network with any other streaming users or downloading applications or network databases or anything of that sort.
I verified that the roonserver and raatserver processes are both already firewall exceptions. Per your instructions, I added them as antivirus exceptions, too. One other thing I did before I got your note was adjust the size of the Windows page file, which appeared ridiculously small (a little more than 1GB) for an 8GB machine.
Also, indexing is enabled, but once Windows has gotten through the initial labor of building the indices, updating when new files are added imposes virtually no meaningful overhead.
I haven’t noticed any pattern yet, but I’ll make a point now of noting as many details as I can when it occurs.
Thanks for that info. Yes, knowing if there are any patterns to the issue will help us narrow down where exactly things are going wrong. One other thing here – you mention that you are using an ASUS router. As per our Networking Best Practices can you please double check to make sure that you have “Enable Multicast Routing” configured in the router settings?
The server communicates with the router over a wired connection
The core and storage are on the same machine, though on different SATA attached SSD devices.
The DAC is connected directly to the machine via a USB port.
I use the Roon app on my iPad, iPhone, and laptop, and all those use WiFi.
“Enable Multicast Routing” appears to be an option on this router when enabling IP-TV support. Since I’m not streaming any services to Roon from the Internet, I’m hesitant to open it up to IGMP proxying if it’s not necessary. (Keep it simple rule and all that.) Can you explain this more? Thanks!
To answer your question about broadcast protocol, we use multicast to discover Roon clients on the network. If you restart Roon on the NAS, the core sends discovery packets to the network saying it is online and any Roon app that listens for those packets can connect. In your case, it seems that after some time the Core’s discovery packets aren’t successfully reaching the network.
This router has a lot of configuration options. So . . . for example, do I go under the “Professional” tab for wireless settings and set “Enable IGMP Snooping” to “enabled” and leave “Multicast Rate (Mbps)” as “Auto”? AND would I change that setting for both bands?
OR
Would I make the changes under LAN-IPTV? That has some slightly slimy firewall implications, which is why I think it’s under the Professional tab.
I’m a reasonably technical guy, so I always check everything twice before flipping switches. Thanks!
And there’s the rub: there’s no simple “Enable Multicast Routing” switch. On this router, that switch is associated with a variety of other IPTV configuration options like “DHCP Routes,” “UDP Proxy,” “IPTV STB Port”, “ISP Profiles,” etc. The professional tab seems like it’s presenting the correct options under slightly different names.
Generally speaking, you would want to make sure that multicast routing is enabled and I can’t comment on the specific settings needed for your router, so I think it’s best to clarify a few other aspects first.
You mentioned that this issue occurs for local content, is there any specific pattern to the type of content that this behavior occurs on? Higher sample rates, longer tracks, specific formats only (DSD/DSF?).
This behavior occurs on the Schitt Bifrost, but does it occur on other endpoints as well? If you temporarily use “System Output” or another zone, do you still experience this issue? Is the Bifrost using the newest firmware version? This will be useful in tracking down if it is endpoint-specific or if this is related to the Core/Network.
99% of the files stored in FLAC format. There are a few MP3s and AACs floating around, but it’s a very small number.
The USB driver for the Bifrost is current. The DAC itself is the most recent multi-bit hardware version. For this product, they don’t offer firmware upgrades. If they improve the design, you can send it back, and they’ll upgrade the hardware. I can say that the DAC has never failed to perform perfectly during the years I’ve owned it, and sound has never, ever stopped.
I’m going to hold off on the router tweak for now because it feels a little bit like swapping tires to see if there’s a flat one. I think logging when the stops occur with as much relevant data as possible will reveal.
