I’m having problems with 1.3. I upgraded to build 194 when it was released last week, and I’m still seeing the same problems now with build 200. Initially, I noticed that audio analysis would keep restarting typically after a few hundred tracks. Sometimes I noticed what looked like full rescans of my library when I looked under “Storage”. The clients keep restarting every few minutes (iPhone, iPad and macOS). I saw that others were having problems with Linux SMB/CIFS setups, and I assumed that this was my problems as well as I was seeing occasional “Not responding” messages in the log. Tonight, I tried to disable the smb mounted NAS share and work with an all Tidal library, but I still saw timeouts and clients restarting every few minutes and music will stop playing sometimes. Both with and without the SMB mount enabled I notice very high packet loss when pinging the system running the Roon Core server (20-50% when monitoring for several minutes). When I revert back to a 1.2 build and database everything works as before with 0% packet loss and no client hickups.
My setup is: Drobo 5N NAS with smb mounted share on a Linux Ubuntu 14.04 system. The system is an ASUS VivoPC (i5 3337U CPU), 16GB and an SSD drive for OS etc.
@support, let me know if you have any suggestions or want me to share more details.
This may get you nowhere but I ran into a similarly strange problem (not with Roon, though).
A quick googling shows that this box uses a Realtek Ethernet chipset. If it’s the 8168 then there is no default driver in Ubuntu and the system loads the 8169 instead. This works but can be unstable under certain circumstances.
The fix is to get the 8168 driver from Realtek and build the kernel module.
When my box started acting up I found an error in dmesg relating to missing firmware and ultimately ended up at the above solution.
Thanks for the tip Andrew! Like you suspected my system was indeed running the 8169 driver for the 8168 chipset. I replaced the driver and so far everything seems to be working much better! I’ll report back if I see more problems, but it looks much more promising than before. Background audio analysis is still running, but packet loss is 0 now and I’m able to play music without the clients reloading like before.
Unfortunately, (after a couple of hours where things seemed to be working) I’m now seeing huge packet loss again and experiencing the same problems I reported before the network driver update
Thanks again Andrew! This does indeed seem to have helped, and I’m able to start up with 1.3 (build 200) again on both server and clients. I did notice that it didn’t seem to do a full background audio analysis scan of all tracks this time (<100 tracks were scanned, but my library is > 10000).
Quick update: The system appears to be able to work through a full background audio analysis run after I changed from specifying the network share path to using the actual folder path on the system instead.
Hello, I am using the Linux core also, but on audiolinux (archlinux distribution). I seem to have similar problems, however I am not technical enough to try to do all you suggested.
My problems are that after playing one or two albums, in choosing a new album, I get the loading page… roon keeps loading but nothing happens. After that, when I go to Overview, or Album nothing happens. Black screen with the loading icon. Strangely enough the music keeps on playing, but the progress indicator has frozen.
I use a dedicated Linux machine. A synology NAS, Tidal. The remote is on a windows 10 laptop, but I had the same problems on a Samsung tablet.
I made a backup folder on the NAS, and backed up a few times. Today that doesn’t work either. It says it can;t connect to the folder.
I’m still seeing huge packet loss. Using the actual mounted folder as opposed to the network share (behind the mounted folder) allowed me to do a full audio analysis scan, but after a while I started seeing huge packet loss again. I’m seeing the same with the new build 204.
Hi @kipe ---- Thank you for the feedback here and my apologies for the slow response. Can you please verify for me how you are measuring the packet loss?
I was just doing standard pings to the server with 64 byte packets from another host on my network. FWIW- I see this every time there’s a new update (with build 208 as well now). After a while, it seems whatever might be causing this backs off, and the system appears more stable again.
Hey @kipe – not sure how much we can do for you here. Packet loss is generally more indicative of a hardware, OS, or driver issue,not something in Roon
I would really be looking at things like bad cables, bad ports, etc. Ubuntu 14.4 is a little bit older, but upgrading to a newer version is no guarantee either.
I realize you mentioned this:
This is really surprising. You can reproduce this consistently? You’re pinging the Core machine from a different device, and you get packet loss with 1.3 Core running but not 1.2?
This is truly strange as I can’t see how all of these are interrelated.
Roon 1.2 works without any similar issues. Correct?
You’re observing periodic packet loss from pings immediately after a Roon upgrade and then for some time after that.
Your library is constantly being re-analyzed. Is that correct?
Changes to your networking config (kernel driver and IPV6 deactivation) helped for a while, but then it all went downhill again.
I have to wonder if there’s some sort of issue between the SMB implementation in the Drobo and Ubuntu 14. Roon’s handling of SMB mounts on linux changed in 1.3 and the new command structure may have caused an issue.
Just for grins try copying a subset of your library to the system drive on your core (or an external drive) and disable the watched SMB share. See if eliminating SMB from the equation changes anything.
Yes, it seemed to be worse immediately after upgrades.
This is no longer happening. Might have been an issue fixed in one of the incremental builds after 1.3.
Yes, it seemed that some of the suggestions that you made helped for a bit, but then I’m back to seeing packet loss and client disconnects after a while.
I’ll give your suggestion a try. I haven’t had time to fiddle with this for a while, but that seems worth a shot. Thanks! I’ll report back.
