Debian 10 (running in a bhyve VM on a FreeBSD 12.2 host)
1 Intel Atom CPU C2550 @ 2.40GHz
2 GB RAM/2 GB swap
The VM is hosted on a SSD
Network Details
Wired Gigabit Ethernet
HP 1810-8G v2 managed switch
MikroTik hAP ac router
250/50 Mbps fibre
Audio Devices
Raspberry Pi 4B endpoint, running RoPieee (3.107 stable) and connected over wired Ethernet.
The endpoint is connected to a RME ADI-2 Pro FS R BE ADC/DAC over USB.
Description of Issue
Roon Server crashes and restarts when playing high resolution content from Qobuz, typically 10-20 seconds into a new song. Playing CD quality material does not seem to cause any crashes, nor does playing any content from my local library or Tidal (in any bitrate/resolution). Sometimes I can play several tracks from an album before a crash, sometimes the core will reboot after a track or two.
I cannot find any indication of any problems in RoonServer_log.txt or any of the system logs (e.g. out of memory errors, stack traces etc.) at the time of the crashes.
I’m aware my CPU and RAM fall below the minimum requirements and that may lead to issues.
I do, however, find it curious that others have reported similar crashes on their Nuclei, which are up-to-spec (see the two recent issues I linked to above). I’ve also not experienced any dropouts or crashes playing back high resolution material (including DSD64) from my local library or Tidal. Sadly, Qobuz only became available here a few weeks ago, so I can’t say whether the issue was already present in 1.7 or not.
For what it’s worth, upping the VM’s RAM to 4 Gb did not help either. The CPU, on the other hand, I can do very little about. I’ll try disabling the volume levelling to see whether it has any effect. Bit-perfect playback should, by all reason, be less taxing on the CPU. (From what I’ve understood, Roon uses 1 core per zone, so giving the VM more cores won’t help any.)
This log excerpt from a crash earlier today would also indicate that the issue isn’t memory related.
...
05/10 13:01:49 Trace: [Living Room] [Enhanced, 24/48 QOBUZ FLAC => 32/48] [100% buf] [PLAYING @ 0:00/3:29] Seven Times - Lianne La Havas
05/10 13:01:50 Info: [Living Room] [zoneplayer] Open result (Queueing): Result[Status=Success]
05/10 13:01:54 Trace: [Living Room] [Enhanced, 24/48 QOBUZ FLAC => 32/48] [100% buf] [PLAYING @ 0:05/3:29] Seven Times - Lianne La Havas
05/10 13:01:56 Info: [stats] 1353mb Virtual, 710mb Physical, 190mb Managed, 0 Handles, 72 Threads
05/10 13:01:59 Trace: [Living Room] [Enhanced, 24/48 QOBUZ FLAC => 32/48] [100% buf] [PLAYING @ 0:10/3:29] Seven Times - Lianne La Havas
05/10 13:02:04 Trace: [broker/accounts] [heartbeat] now=10/05/2021 10:02:04 nextauthrefresh=10/05/2021 10:32:05 nextmachineallocate=10/05/2021 13:32:04
05/10 13:02:04 Trace: [Living Room] [Enhanced, 24/48 QOBUZ FLAC => 32/48] [100% buf] [PLAYING @ 0:15/3:29] Seven Times - Lianne La Havas
... Here the log file was rolled over because the core had crashed ...
05/10 13:02:11 Info: Starting RoonServer v1.8 (build 790) stable on linuxx64
05/10 13:02:11 Trace: Checking if we are already running
...
If someone from support still wants to chime in, I’d be glad to spelunk around the logs some more or try something else to pinpoint the problem.
Hey @support, since you’re already looking into the related issues I linked to above, you might be interested in another data point (this thread) to aid in your efforts.
We do have a ticket in for a resource leak that can arise in situations like you’re seeing. It’s hard to say for sure that this is what you’re seeing here since the device is under our recommendations and Qobuz hi-res playback tends to be more demanding. Once we have a solution available it could definitely improve things, so we should see how things work then and we can take a closer look if needed.
