My hypothesis from my own experiences and those reported here by you and others is that there may be a networking bug in Android Mono (Mono is the cross-platform C# runtime that Roon relies on) on newer Android releases, which is tickled by some change in network access patterns in recent Roon releases (eg. the switch from UDP to TCP for RAAT).
Any news on this bug? It’s not fatal for me because I also own an iPad, but it’s kind of annoying because I have my Pixel phone in my packet all the time, while I have to go look for my iPad or my Macbook when I want to listen to music. Thanks!
4 posts were split to a new topic: Samsung Tab S4 Android having trouble connecting/staying connected to Win 10 Core
Hi @David_Warren ---- Touching base to let you know that I have contacted you via PM with instructions on how to get logs over to our servers. Furthermore, may I kindly ask you to also please fill out the survey found in Mike’s post above.
Looks like I’m back in the game.
After updating ROCK to build 148, my android remote has connection problems again, after running flawlessly for a couple weeks.
A restart of my phone fixes the problem and the android app can reconnect, but it’s a nuisance doing so every time I come back to my home WLAN.
I answered to @Eric’s PM already, please let me know if you need my logs.
Hi @Kopftelefon ---- Letting you know that I have responded to your PM.
It turned out I’m too stupid to read and understand instructions. (see PM)
I’ll wait for the next occurrence and send you the logs from the affected device.
I’m having issues with android not connecting to the core (Rock on a NUC).
First time I start the app it will connect, but after that it takes a restart of the core server to get it to connect.
I filled out the survey posted in the link I found earlier.
Note3 running android .5.0 and Pixel C running 7.1.2
Once in a while if I let it sit for a LOOONNNGGG time it might connect, or if I disable Wifi on the remote device and then re-enable it, it might connect but only rarely does that work.
Edit adding more details:
I can also confirm that changing the name on the core on my wire PC makes the app on my phone connect immediately, then restarting the app it fails to connect. It’s like it latches on to something and then needs to forcibly disconnected before it can reconnect.
It does not work on my old Note3 that has 5.0 android on it either. Does this affect your hypothesis about the Android Mono thing on newer releases?
Not really. The change I was referring to was RAAT’s change from UDP to TCP, which could have tickled a subtle bug in Mono’s TCP support.
Well, I just updated to Android 8.0 Oreo and I still have this issue of not being able to connect to the core with my Pixel C…
Same experience, even after reinstalling Roon Remote on Oreo.
Well this is getting frustrating, still can’t get reliable connection to the core with my two devices I have been trying, Only way they will connect is by either resetting the server, or I just found out while fussing with my router that changing certain settings on the wireless (MSDU vs MPDU, whatever those are) the Pixel C will loose its wireless connection and then when it gets it back will “most of the time” connect to the core. Not sure what to do next…I don’t really want to buy an ipad just to get reliable control…
That’s interesting, it suggests some issue in packet size/aggregation between layers in the protocol stack. I think I’ll do some experiments this holiday weekend, as I have very fine-grained control over my pro-grade home networking gear. Stay tuned.
Just to let you know you are not just chasing a ghost. I have a Note 3 with Android 5.0, a Note 4, Tab S2, Galaxy S6 and Galaxy S7 edge; all connect to either my ROCK NUC or my Win 10 server. Don’t have connection issues with any of them.
I just updated all of them to verify in case an update had caused issues, as I don’t use some of the older ones all the time. I do use them as mobile endpoints though and they work well for that.
I am pleased for you, but some of us are having connections issues with Pixel C, Z3 Compact, Z3 Tablet, Z4 Tablet, so no ghosts here, just constant reboots of the server to get connection.
So here’s another interesting thing. I was doing some more trouble shooting. Started with the usual things clearing cache, clearing data, forcing stop, and then finally reinstalling the app. This seemed to help the Pixel C some but the Note 3 not at all.
I also went through a house cleaning on my router getting rid of all the old entries for devices and computers I no longer have (mac filtering). I tried tuner things on turning things off (too long a list to put here). Nothing seemed to help other than when the setting forced a reset of the communication to the devices. It was also not 100% consistent with the way it responded to the changes.
Then I thought about the different setting available fo the apps in app manager and elsewhere on the devices. Like notifications and permissions. I shut notifications down for the app on the note 3 and bang it works now (mostly, still not 100%). I tried it on the Pixel C and sure enough it works much better. Lots of starts and stops of the app so the percentage is pretty high of working connections (still not all the time though). Oreo has a few more options for apps than 5.0 so on the Pixel C i also took away the permission for accessing my contacts from the ROON app, that seemed to help a little but i think it is the shutting down of notification for the ROON app that made the biggest difference.
I know very little about what this really means and for all i know it just magically works now, But I did turn notifications back on and it seemed to get worse. Not sure if this helps any or not or just muddies the water a little more.
Thanks I will test this and see if it makes a difference for me also.
Also when I went in and changed the settings for the Roon App I got a warning message saying:
“This app was made for an older Android version and might not function properly”
Did you also get that when changing the “rights” of the App?
Yes, I did see that message. Also got the error about the app might misbehave if I take the permission away… but it is already misbehaving so…
Wanted to provide another update as we continue to try and understand the conditions under which this issue occurs.
As I’ve mentioned previously, no one on the Roon team who uses Android has ever seen this issue occur in their own homes, nor have we heard it reported by any of our 40+ alpha testers.
Rough estimates are that this affects less than %1 of Roon Android installs, and I say all of this to be clear why we are having such a difficult time making progress – it’s often extremely hard to reproduce and resolve issues without reproduction steps that consistently trigger the issue in a debugging environment.
We had some hope that this issue might be resolved in Android 8.0 but all signs point to this persisting even when running the latest pre-release versions of Android.
Our testing continues, and so I wanted to provide a few updates here.
We have noticed that an inordinate number of affected users are using Ubiquiti networking gear. For those of you in that group, it would be a hugely helpful test to see if things are better with that hardware temporarily removed from the network.
Ideally, for that test you would be running a total of 3 devices on the network:
A simple wifi router with default settings
The Roon Core
The Android device
If things continue to fail in that configuration, we would like to know.
While we don’t currently have a good theory on why this would only affect some configurations, it would be great if everyone could get into this broken state, and then try disabling the Android device’s mobile connection by enabling Airplane mode and then turning on Wifi – we are wondering if multiple network connections could be related, so this will also be an interesting test. If possible, it would be great to run this test in the simplified configuration I mentioned above: wifi router with stock settings, Roon Core, Android device. We know that won’t be possible for everyone, but that would be our recommendation for a truly “clean” test.
Finally, we are designing some more intensive tests that we would like to run early next week on some of the affected setups/networks. These tests will require us to coordinate a time to run the tests, and will likely require the user of some additional logging we have in place in ROCK, as well as the ability to run a simplified network as I described above. If you are experiencing this issue on ROCK and think you’d be willing to work with us to run some of these tests, please drop me a PM and we’ll coordinate a time.
We are not giving up here folks, and neither should you. We will keep at this until we have resolved the issue, and I want to say one more time how much we appreciate everyone’s patience – this is one of the trickiest issues we’ve encountered in the history of the company, and we’re as restless as you guys (if not more) to close it out.
We’ll get there. Thanks everyone!