Have they ever worked? You may need to ‘choose an alternative core’ at which point it offers you your core device as the only option. Also make sure your core is the very latest version.
Thank you for response.
No, they never worked. It’s an all new installation and the app was never able to find the core. I did also several new installations of the app during testing. Nothing helped so far. The core and the devices are all in the same 5 GHz wlan.
Despite this, using them as endpoint / zone does work when I configure them from my PC. But I need them as controls.
Do they offer you any options at all?
On the app start screen are the options Help (where you can enter the IP address of the core) and Configure Roon OS devices on your network besides the possibility to change the Language (which is the only one that actually works ).
Or are you asking about the zones? There’s no difference in the options. They are all the same as they are for the working Samsung tablet.
On the screen of the remotes that won’t connect.
I’m new to this issue, having just got an Android 7 smartphone. For me the problem is that the Roon Remote on the phone won’t find the core until I reboot said core. Then the remote works. If I shut the remote down and try to reconnect it hunts endlessly until I reboot the core again. All other Windows-based remotes work flawlessly.
Questions though about the Android remote app. I can’t seem to find the “focus” function, nor can I find any way of quickly jumping to a particular section of the library as I can, using the keyboard, on the remotes I have installed in Windows. Scrolling manually through 2200 albums is pretty hopeless. Also, is the app limited to portrait mode? Landscape would be much better but I can’t get it to change.
Maybe the developers should create a special debug version of the app that support can then send to affected users as they usually don’t have problems to reliable reproduce the issue?
There are maybe hundreds of internal as well as external function calls, any number of them with the potential to stop the app from properly starting. A special version of the app that reports some how what’s going on internally or at least reports what’s failing might help the tech team to figure out what’s going on.
PS: Yes, I filled out your data gathering survey already.
This still happens with the Core and Android Remote update that was just released. My observations:
- The Roon Core notices the RAATServer on the Android client immediately, without fail, every time. This is visible from the logs on the Core.
- The Roon Remote on Android is unable to find the Core when the Core has been recently restarted. After the Core has been running for around 24 hours (could be less, that’s just about the timeframe where I can re-test – but it is definitely more than eight hours) the Remote starts finding the Core most of the time.
- Rebooting network devices or the Android devices makes no change to this behavior.
- Even if you explicitly give the Roon Remote the IP address of the Core, it won’t find the Core when it is buggered. (Which makes no sense to me.)
I will also mention that the services advertised from the Core via Avahi (e.g., the default “workstation” advertisement) as visible on the Android devices having trouble connecting without fail. (I am curious why Roon chose to roll their own discovery protocol instead of using established protocols like Zeroconf or SSDP.)
This happens on both my Android devices, a Pixel XL running Android 9, and a Nexus 9 running Android 7.
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.