I may also be having a similar issue. I just migrated my Roon Server from Mac to Ubuntu 18.04 earlier this week (with build 505), and the Roon server has been crashing frequently since migrating. I upgraded to build 511 this afternoon and now it’s crashing more frequently, almost always within 2-3 minutes after starting to play to Sonos. I don’t see anything interesting in the Roon logs, though there is a crash file in /var/crash. Is there a way to turn debugging to get more info in the logs?
@Robert_Read I do not believe that the issue you are having is the same as the one described in this thread. I would suggest you open a new thread and report the problem with the full description as requested by the forum.
I have split your post into it’s own thread since the previous one may be unrelated.
So we can better assist you, please provide a brief description of your current setup using this link as a guide.
Make sure to describe your network configuration/topology, including any networking hardware currently in use, so we can have a clear understanding of how your devices are communicating.
By “crashing”, do you mean to say that the music stops or that RoonServer exits by itself?
By crashing, I mean the RoonServer exits by itself. The client is disconnected and I see this in the syslog on linux vm running RoonServer:
Dec 27 18:15:01 roon1 start.sh: Error Dec 27 18:15:03 roon1 start.sh: Initializing Dec 27 18:15:03 roon1 start.sh: Started Dec 27 18:15:05 roon1 start.sh: aac_fixed decoder found, checking libavcodec version... Dec 27 18:15:05 roon1 start.sh: has mp3float: 1, aac_fixed: 1 Dec 27 18:15:07 roon1 start.sh: Not responding Dec 27 18:15:12 roon1 start.sh: Running Dec 27 18:22:28 roon1 start.sh: Error Dec 27 18:22:30 roon1 start.sh: Initializing Dec 27 18:22:30 roon1 start.sh: Started Dec 27 18:22:31 roon1 start.sh: Not responding Dec 27 18:22:31 roon1 start.sh: aac_fixed decoder found, checking libavcodec version... Dec 27 18:22:31 roon1 start.sh: has mp3float: 1, aac_fixed: 1 Dec 27 18:22:36 roon1 start.sh: Running
This occurs frequently when I play stream to my Sonos system, two Play5 in a stereo pair, but not every time.
The Core is running in an Ubuntu 18.04 LTS VM on a FreeNAS host. Hardware is an AMD Rizen with 32GB RAM, and the VM has 4 GB dedicated ram.
The network is all Ubiqiti hardware. The VM host is directly connected to a Ubiqiti managed 8 port 1Gb switch, and the Sonos are on wifi connected to a Ubiqiti access point. All the equipment is in the same room. The AP is connected to the same switch as the host, and it is about 10 feet from the speakers.
I have a ~6500 tracks stored on the FreeNAS host and accessed in the Core VM via an SMB mount. I’m using both Tidal and Qobuz services. The crash may occur more frequently when using Qobuz, though that may be just because I’ve been using it more lately. I’ll pay attention to what source is playing when crashes occur from now on.
The Core just crashed three times in a row playing a Tidal track, so it’s not specific to Qobuz. The same track played all the way through after the 3rd crash, though.
Happy New Year and apologies for the delay in getting back to you, I have been traveling these past few days.
Can I please request that you send me a copy of your Roon logs by using these instructions? I am wondering if the logs provide some more context towards the issue.
Happy New Year! I finally had a chance to play some music so I could reproduce the problem. It happened while streaming a Qobuz track on 01/08 04:15:44. This is at the end of the RoonServer_log.02.txt. This time it was not playing to Sonos, it was playing to a Hugo2 connected to my Macbook, which is also running Roon 1.7 build 511.
Thanks for sending that log file over. That’s strange, it appears to abruptly end at the end of RoonServer_log.02, so it looks like you’re getting an unmanaged crash. I wonder, does the Ubuntu system log provide any further details?
I don’t use Ubuntu too often, but according to their docs:
Many applications also create logs in /var/log. If you list the contents of your /var/log subdirectory, you will see familiar names, such as /var/log/apache2 representing the logs for the Apache 2 web server, or /var/log/samba, which contains the logs for the Samba server. This section of the guide introduces some specific examples of application logs, and information contained within them.
Can you check to see if there’s any info for Roon in var/log?
There are no Roon-specific files in /var/log that I can find, though there is an apport.log.1 file from yesterday with some information about this crash:
ERROR: apport (pid 13112) Wed Jan 8 04:15:48 2020: called for pid 12669, signal 11, core limit 0, dump mode 1 ERROR: apport (pid 13112) Wed Jan 8 04:15:48 2020: executable: /opt/RoonServer/RoonMono/bin/mono-sgen (command line "/opt/RoonServer/RoonMono/bin/RoonAppliance --debug --gc=sgen --server RoonAppliance.exe -watchdogport=42351") ERROR: apport (pid 13112) Wed Jan 8 04:15:48 2020: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment ERROR: apport (pid 13112) Wed Jan 8 04:16:26 2020: wrote report /var/crash/_opt_RoonServer_RoonMono_bin_mono-sgen.0.crash
Unfortunately it seems that crash dump is not very helpful:
rread@roon1:~$ sudo apport-retrace /var/crash/_opt_RoonServer_RoonMono_bin_mono-sgen.0.crash ERROR: Invalid core dump: BFD: warning: /tmp/apport_core_pob79nxd is truncated: expected core file size >= 1072156672, found: 420544512 warning: core file may not match specified executable file.
Last update for tonight - I just did an apt update and upgrade and still saw the crash. And got similar error when trying to get a trace from the crash file.
For the record, my current version of Ubuntu is
Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-74-generic x86_64)
Ah, the classic software developer move to blame the hardware. Yes, it is a seg fault, but not all set faults are caused by hardware. Faulty software can also cause them, and since this is the only application that is faulting, and it only occurs during specific conditions (when playing music from a streaming service), it seems unlikely this is a hardware fault. I will try running memtest when I get a chance, though.
I agree that a seg fault can be caused by different reasons, but since the logs aren’t showing much info it’s best to exonerate the hardware aspect before we proceed further . Do let me know how memtest goes.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.