@support I guess this might be of interest. Output is of journalctl from systemctl start roonserver.reservice until stopped manually. “Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application.” Cheers. [Edited link, Dropbox doesn’t like files without extensions I guess]
Hi @lorin ----- Thank you for the follow and I am sorry to hear that this issue has persisted. I have left a note with my team to re-open our discussion based on these most recent findings you have made and once I have some feedback I will be sure to follow up with you accordingly.
-Eric
Thanks Eric, I’m in the process of a fresh Arch Linux install to rule out any gremlins from old configurations, etc. I will report back later!
Ok, so: Brand new installation of Arch Linux. ~400 packages installed, only the basic dependencies necessary for xserver, sound, browser, hq player & roon. Pacman.log showing all packages and their versions. Exactly what anyone who installed Arch today would be running. 4.9.7-1-ARCH kernel, systemd 232-8.
Stock configurations, connected using netctl through wired ethernet [text of ethernet-dhcp profile] with Cisco DPC3825 DOCSIS 3.0 router/modem. Cable internet, Shaw Communications. Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c). Output of lspci.
Output of roon log from service start to attempted connection. iOS devices can’t connect to Roon, internet on main machine is substantially slowed by roonserver.service. No meaningful connections made.
Output ofjournalctl --all for same time period; includes core dump of Process 10073 and stack trace of thread 10091.
pstree on startup
htop
Starting to feel like a jerk for posting and posting and posting, I apologize. Not quite ready to give up. I really want roon in my life!
So anyways, I’ve managed to load my library again and connect with my iPad. Web browsing is good. Trying not to get my hopes up as I had a brief period like this before. And I guess that’s the most vexing thing about all this… no apparent cause and effect. Nothing changed since this afternoon when I gave up after the clean install and yet music playing happily now.
I’ll report if things are still stable tomorrow. Thanks again.
So far so good. The most promising lead here is that the control panel for my modem/router has a place to explicitly specify DNS servers. The default (blank) had been working but … possible some kind of clash between this and whatever in Mono that might relate to DNS resolution?
Long story short (not my forte I know) I’ve explicitly specified my ISP DNS servers, with Google’s as a backup. Could this be it? Will keep you posted.
Sorry – I LOLled. 
That notwithstanding – it reads like a whodunnit for nerds. Keep it coming – and here’s to a happy ending!
1 Like
I guess @RBM is my good luck charm.
Explicitly specifying dns at the router level seems to have done it. 24 hours of crash-free operation and everything sprang to life instantly after being left idle over night. Moved my database to a SSD and it’s never been faster. In the end, I feel I’ve learned a lot. So, resolved!
I’ll think I’ll remove a bunch of these logs from Dropbox in a couple days so they’re not floating out in the ether.
Now on to playing with some of these new features.The linked performances for individual songs is incredible. 
5 Likes