Mid 2011 Mac Mini dedicated to only run Roon Server headless. MAC OS 10.13.6, 2.7Ghz i7, 1TB SSD OS drive, 16GB RAM
Networking Gear & Setup Details
Gigabit LAN connected to LAN switch. No VPN. Synology 1517+ DSM 7 for music storage.
Connected Audio Devices
rPi streamer, LAN connected. Ropieee XL installed. USB connection to DAC.
Number of Tracks in Library
113000 tracks
Description of Issue
2 issues:
Roon remote suddenly shows message “waiting for roon core” music drops out for a few seconds. Server is reconnected soon after. Music paused and needs to be played again.
Music stops. Message “An audio file is loading slowly. This may indicate a performance or hardware problem.”. Wait a few seconds and play again everything is fine.
In both cases it happens intermittently. Files played back are mostly redbook 44.1. I could be playing a DSD 64 file with no issues and a 44.1 would cause Roon to dropout.
I realise the hardware isn’t optimal. However CPU loads are minimal and memory seems sufficient for Roon and system swap files. I have noticed that when Roon drops out temporarily CPU spikes to almost 100% load for a split second before recovering back to normal.
Thanks for taking the time to reach out! It’s great to see you on community again. I’m sorry to hear you’re running into issues with your core and remotes disconnecting.
You are correct in that your machine is a bit on the outdated side. That said, we can certainly try to clean things up for you.
A few follow-up things to test:
Bypassing your network switch, and hardwiring your core directly to your router
Playing audio directly from your system output
Let me know if your issues persist after testing the above. Also, if possible, please share a timestamp (date,time) the next time this issue occurs. That way, our team can enable diagnostics on your account and take a deeper look into what’s happening specifically at the time of the issue.
Ok, core server (mac mini) connected directly to router. Playing audio from mac mini output was perfectly fine. No droupouts whatsoever. Bearing in mind all files (192k, DSD64 etc) were resampled on the core to match the output capability of the mac mini system output.
I assume this means the core is running fine and there’s a network bottleneck somewhere?
Thanks for letting me know! You are correct here, it sounds like the culprit is related to your LAN switch. If possible, are you able to provide more information on your switch? Is it managed or unmanaged?
A few things to consider:
Sometimes, switches will have 1 port that remains active while all others eventually fall into a sleep setting. I would try different ports on your switch and see if that replicates or issue or not.
Try power cycling the switch and see if that makes a difference with your issue.
Changed all Switches to newer TP link model. Updated all associated LAN cables to CAT 6e. Still getting dropouts.
See image below for network map.
Backtracking to playing on the core system audio output, i managed to get a dropout today 11.50pm +8 GMT. Will continuing monitoring. Update: Not been able to replicate dropout on the Core System output since. Rock solid stable on the core machine.
Playback on core system output of local music files stored on NAS. Update: Stable since the indicated dropout above.
Playback of streaming off tidal on DAC. - Update: Prone to dropouts intermittently.
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
7
It would be interesting to see if the problem persists when the rPi is connected to the same switch as the Core Mac Mini. I wonder, too, if the CPU spikes correspond to the Core scanning the SMB-mounted volume on the Synology for changes.
Good point. Worth an investigation. However i have set the core to only scan volumes on startup since this problem started. So it doesn’t scan volumes (or not supposed to) otherwise.
I guess one way to negate the smb problem is to have the volume sitting on a RAID drive directly connected to the core machine by USB. Or have the files sitting on a local HDD. This is one of 2 last ditch attempts should nothing work as copying that many files over is going to be a pain. Second last ditch attempt is to do another fresh install of the OS on the core machine.
Having the rpi connected to the same switch as the core is possible… tho i got to figure out an audio output that could work for testing, The 2nd switch as you may have guessed sits at the AV console, physically different location to the core and other switch.
I wanted to check in on this thread to see if you’re still running into issues? I’m curious if @Bill_Janssen’s suggestions led to any solutions?
If not, please jot down a timestamp (date,time) the next time your core drops, and let me know. Our team will enable diagnostics on your account and take a deeper look into what might be going on at the time of the drop-out
As it turns out one of the drives on my NAS which stores music files crashed and hence went into degraded mode. I am restoring the setup before i can resume testing.
