It used to happen consistently on my Pixel, and later Pixel 2 XL, as well on a Nexux 7 tablet I’ve not been using for a while. However, since I turned off IGMP snooping on the managed Netgear switch that sits between my wireless AP and the Ubuntu NUC running the Core, the problem has not returned.
Hello. I have exactly same subject with Android devices (Samsung S4, LG G6, Tablet Asus ZenPad 3S) where as there is not subject at all with all my other devices running Windows.
Happens only since beginning of this summer. During my trial period before that, I never had this connexion problem.
I must confess that it prevented me from getting lifetime licence and stay with annual renewal.
Hi everyone, came across this threat because I was having the same issue. After reading about the netgear switch (I have an old unmanaged one), I decided to take it out and connect my NUC i5 running ROCK directly to my new router (TP link AC 3150). It’s been working great for the past few says. Hope this helps someone. In my case there was definitely a problem with the switch/new router combo.
Yeah, I’ve been tracking this issue since the beginning – I was one of the first to report the problem – and my hypothesis that there’s a bad multicast interaction between Roon on Linux, some Ethernet switches (especially Netgear) and Android keeps getting bits of additional support, like your experiment now. In my case, turning off IGMP snooping on a managed Netgear switch did the trick.
Can somebody explain to me why this issue still exists?
I understand that Roon development hasn’t been able to reproduce the problem. But I’m sure that the developers have spent more time trying to identify the problem that it would have taken to write a more robust core-controller handshake routine. They should have enough customer data at this point to narrow the problem down to a fairly small area of code.
I’m sure Roon is losing customers over this.
Having done a lot of debugging of this problem on my own and with Roon engineers, I am skeptical that this is a simple matter of “more robust.” My suspicion is that the bug is somewhere in the Mono runtime or the Linux network stacks in Linux servers or Android and how they interact with the network switches, so there’s no clear above-the-OS-and-runtime fix for it.
If it were in the OS, some other app would have problems. TeamViewer never has this problem. Other apps I use to stream across my LAN don’t have this problem. It’s not like the controller needs a huge or fast connection to the core. If it takes a half-second for music to pause, I’d guess most of us would prefer that to the current situation.
But if you restart the service after boot, is it working?
my experience was that the initial connection works just fine. It’s reconnect after the remote it shut down or goes to sleep that the issue occurs. changing any setting in my network configuration forces it to reconnect, for me at least. But, ever since I turned on the wireless on my nuc rock in addition to it being connected by ethernet, I haven’t had a issue with remotes connecting.
Not really. You don’t know which code paths in the OS are exercises by which programs. The combinatorics of the situation is such that a race condition can be there undetected until a very particular combination of system calls and responses shows up.
That’s quite possible. That’s why you just rewrite it – to use completely different code paths. Especially since plenty of other software performs similar functions without a problem.
Modulo the small problem that “similar” != “identical”.
Of course, had they used an existing discovery protocol like Bonjour from the getgo instead of rolling their own, they wouldn’t be in this position since those discovery protocols are all provided by the OSes now (well, except for Windows, but it’s easy to get Bonjour on Windows anyway) and have been well tested and work reliably on all platforms.
For me, it’s the opposite. When the Roon Core is restarted, it will be approximately 24 hours before the Android app starts to find it.
From various comments by Danny and Brian in the forum, the remote code is (or was) apparently done by a single guy who isn’t a programmer, but rather a designer. Roon Labs wrote their own design language for this guy to describe his design with, along with a compiler that takes it into what is apparently their .NET/Mono/Xamarin (for Android/iOS) infrastructure. Things may have changed since those comments were made, but fixing network bugs with a stack like that would be difficult, like poking a 1-cm button with a jointed 10 m pole.
I have this problem only when I restart the machine running the core after upgrades (Ubuntu 18.04.1 LTS at the moment). Restarting the roon processes fixes the problem immediately.
My Android Tablet (Samsung Galaxy Note 8.0) can no longer connect to Roon. It was working well yesterday (Roon 1.5 version 233). When I tried starting it today, I got the message “Unfortunately, Roon stopped working”. Noticed on Application Manager that there had been an upgrade to version 254. Could this be the problem?
If it says 254 on your Note 8 it still needs to be updated to 354… Roon 1.5 (Build 354) Is Live!
My note 8 phone is working fine and it is on Roon version 1.5 (build 354).
My mistake. It is actually 354. Version 323 (if I remember correctly) worked okay. The update seems to be giving the tablet trouble. I’ll try to uninstall and reinstall and see if that works.