Baah… to easy.
Not working today, same as before core update with android remotes not connecting.
@mike Any progress on this issue? I wish I could send you more detailed logs, but unfortunately the Android app does not even get to a point where I can do that, it gets stuck looking for my Roon core on Ubuntu – which can be reached reliably from iOS and macOS.
1 Like
This is a really sneaky bug. Just came back to my Nexus 7 that had been sitting on a shelf plugged into its charger for a week, and it had found the Roon Core that it had failed to find before I just gave up and put it on the shelf. If things proceed as before, at some point the Nexus 7 will lose the core and not be able to find it again, even if Roon Remote is reinstalled or the Nexus 7 is rebooted. It’s as if the core at some point decides that the remote is unreachable, and sets some internal flag to ignore it indefinitely, until enough time passes or some other event (core server being rebooted is not enough in my experience). I know that the core receives the initial contact from the remote because core logs show that initial negotiation.
2 Likes
I get this pretty often on all remotes iOs or android. Very annoying bug a restart of the device is the only thing that cures it.
1 Like
Nexus 7 still talking to core happily. Just tried Pixel after weeks of failed attempts, and it sees the core too! This is so baffling. I’ve not changed anything on my network, except that I rebooted the NUC that runs the core two days ago for a standard Ubuntu update. But I had done that several times before without effect on Android remote connectivity.
Arrgh! Both Android devices just lost the core since my last message, while my iPad keeps seeing it fine. Neither Android remote app gets to a point where I can get a support package. I continue to suspect that the problem is in the core: when an Android device sleeps, the core concludes it is unreachable and never accepts connections from it again.
All — Thank you all for your patience while we have been actively discussing our next steps forward here, in regard to addressing this behavior you’ve reported to us.
To catch everyone up to speed, we had two meetings with our senior developers last week to discuss and get some theories on what could be causing this to occur in certain setups and not others. The team is currently iterating on our notes and compiling all of the given feedback into a survey which we will be using to gather data from anyone who has reported this issue to us.
Due to the fact that this behavior seems to “come and go”, we must begin looking into this issue by searching for any similarities or commonalities in your setups to determine if there are any patterns we are seeing. Our hope is that the information obtained via our survey, coupled with our analysis of your logs will reveal a general cause (or causes) to these connectivity struggles you have been experiencing.
Please rest assured that we have not given up and plans are currently in motion to dig deeper into this behavior.
-Eric
1 Like
I’m having the same issue:
Samsung Note 8.0 (GT-N5110) running Android 4.4.2
Roon ROCK Intel NUC6I5SYH
Netgear R9000 Router
Netgear R7000 in AP mode
Win10 Roon Control
Apple Ipad Pro Roon Control
Rpi3 X2 Roon Bridge
Sonos X3 Roon Endpoint
Everything is working correctly with the exception of the Android device. It worked initially when I set it up for portable connection to a Bose Bluetooth speaker, but would not find the core after initial shutdown.
Thanks for the update Eric, much appreciated. 
OK reinstalled app and this still happens. What I have noticed is that it only seems to happen if tablet or phone left for a while and WiFi has disconnected. I you start Roon before the WiFi says it’s connected then app will point blank refuse to find the server even WiFi comes up. A reboot of tablet sorts it or maybe it will connect at some point again after if left for long enough.
What setting do you use for the ‘Keep WiFi on during sleep’ option? I have it set to ‘Always’ on both my Pixel C and Nexus 7 and don’t have the issue.
Does it connect after you disable and then re-enable WiFi?
Just to add another +1 for this with my Z3 Compact & Z3 Compact Tablet struggling to see the core.
It finds the core after a core reboot, but my macs find the core straight away without core reboots.
Hi, I’ve also been experiencing this issue consistently. My core running on Fedora, laptop. Remote on Google Pixel phone.
After a new start of the server, I can connect by remote just fine. If I always keep the Roon remote app open and active (so that it is displaying playback, screen is not off, etc.), I don’t seem to have any connection problems.
If I close the app and then open the app again after, say, 3-5 minutes, I will be unable to connect to the Core. This is almost always the case, with very few exceptions. This is also the case if I don’t close the app myself but simply turn off my phone display for 3-5 minutes, so that I have to go through the lockscreen and then roon remote restarts and (unsuccessfully) tries to connect to the server.
If I restart the roon server (say by systemctl restart roonserver.service) I can reconnect. I am always able to use an iphone remote to connect to the server, even when the android remote cannot connect.
This aligns well with my observations. From also looking at core logs, I’ve formed the hypothesis that Roon Core 234 somehow mistakenly senses that an Android Remote is unreachable, and then sets some internal state that blocks any further handshake with that Remote.
2 Likes
This is driving me to strange desperate lengths to try to get my handheld Roon controller back.
Just in case something somewhere in this communication was allergic to the Asus WiFi access point I’ve been using (reliably with everything except Roon Remote), I thought I’d give a Ubiquiti UniFi access point a try.
I got it configured, switched my Pixel XL to its wireless network, and… Roon Remote worked!
For awhile. Then it seized up again.
I have no idea what made it work, and what made it stop working. Powering off and rebooting the access point didn’t make Roon Remote connect. Stopping and re-starting RoonServer didn’t make a difference. Rebooting my phone didn’t make Roon Remote work. I didn’t try shutting down and restarting the host RoonServer runs on, because that’s a giant pain in the ass which didn’t make a difference the last time I tried it.
Note that when the Android phone went from not working to working, RoonServer had been running continuously for many days; all that had happened was tearing down and rebuilding the WiFi network… but see my failure to recreate this effect via power cycling.
Since I’m guessing few people’s networks include the copper<->fiber media converters at each end of a run of fiber featured in our house on the way to the WiFi access point, I began suspecting them (even though laptops running Roon and phones running everything but Roon are using that network path successfully); so I strung a long messy run of Cat6 to feed the access point so the whole run between Roon server host and access point was plain copper.
No change.
Is there anything we can identify as common across setups where Roon Remote is failing? Are we all using WiFi access points which are separate from our routers and bridged to the rest of the LAN? Are there commonalities in Android versions or Android-device hardware? [The latter seems a bit unlikely, because even just the Android hardware I’m trying spans a few flavors of hardware and software.]
Did the UDP-to-TCP protocol change spoken of as included in the recent Roon release change communication to the Roon app, or just communication to playback zones?
Is the server not just trying to connect to the app as a controller, but also to connect to it as a potential playback zone? I think I see hints of that in the logs. If the Core is trying to hook into the Roon Remote app as a potential playback zone, could something about that negotiation be poisoning the well?
Is there any way to configure the Roon app to force it to act as purely a controller, with no attempt to be a playback zone?
These are the things I keep thinking about as I flail around trying to see if I can get functionality back.
Do I need to buy an iPad? That would truly be an act of desperation.
Your experiments and analysis match mine. I’ve been using a UniFi AP all along, which worked perfectly for years. Like you, I have a funny feeling that the UDP-to-TCP change in RAAT together with the remote being treated as a potential playback zone might be tickling some bug in Android networking or the Android Mono implementation that causes the core to decide the remote has gone AWOL.
And yes, my iPad works perfectly as a remote. If I had not got an iPad last month for other reasons (long story), I’d be as stumped as you are.
1 Like
I haven’t found a systematic way to the Android app to connect to the core. Sometimes just rebooting the core fixes it, sometimes I have to reboot the core multiple times and/or reboot the Android (Samsung S6 on Android 7) to get it to reconnect…
It’s set to always. Not tried disabling enabling the WiFi might try that next time it happens.
Hi everyone,
First off, we appreciate everyone’s patience as we’ve worked through this issue. When we get a clear set up steps to reproduce an issue, our team can almost always identify the issue quickly, and in many cases we can resolve it for our next release.
In this case, the reports have stretched across a number of releases, platforms, and configurations, and to complicate things further it’s not something anyone inside our company has seen with any regularity, despite the fact that more than half our team uses Android devices in their homes.
With many, many users running our Android app without issue, obviously there is something unique about the affected environments that is triggering this behavior, and we need to figure out what this is so we can investigate this issue in a controlled environment and resolve it.
Our team has been actively discussing what could be causing these connectivity issues in certain configurations, and our QA team has spent time trying to identify the conditions that trigger this issue. Particularly because these reports often appear to be intermittent the results have been largely inconclusive…
After numerous internal discussions, we’ve decided to take a more methodical tack and gather all the reports and troubleshooting steps in one place. We are aware that, for some of you, this will feel like you are repeating yourselves, but the goal here is be comprehensive – to get all the setup details in one place, and to get all the troubleshooting results in one place, so we can identify any patterns that might help us consistently reproduce this issue in-house.
At your earliest convenience, it would be great if everybody could fill out the survey found here. We really appreciate everyone taking some time to run through the questions and steps listed in the form, even if you’ve already provided this information to us elsewhere.
Looking forward to making progress on this and getting it resolved soon. Thanks all!
2 Likes
Hi Mike,
I did the survey but it is a bit shaky, for example the last question when you shut-down the remote and try to reconnect. That worked the first time i.e. I answeared that it worked. After finishing the survey I shut-down the remote again and then it could not reconnect …
Also the question “Have you tried disabling all firewalls”, when you have no firewalls to disable … then you need to answear “No I have not disabled the firewalls” …