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!