New Roon setup. Primary use is Nucleus One feeding Mcintosh MDA200 DAC over USB. Windows 11 client seems to work fine. Problem is with Android client running on Samsung Galaxy Tab S9 Ultra, Android 14 and OneUI 6.1.1. After a listening session, I close the Roon app. When I restart it for the next session, the app stays in "Waiting for Server" status. If I power off/on the Nucleus, and then restart the app, it connects. Need to have the app connect without having to do the power reset.
Describe your network setup
Router is Netgear Orbi. Switches are Netgear. Nucleus, DAC and Windows PC are on ethernet. Android tablet is on Wifi.
Conducted some tests in attempt to isolate problem.
Bottom line: Problem appears to be specific to the Android client and may be associated more with the Android client sitting idle for awhile than anything else in the environment. Seems as though once the Android client recognizes some type of event such as touch input or a reset of the server, it “wakes up,” but only after about a 10 minute lag.
Environment:
Roon client 2.0 build 1496 64-bit on Windows 11 desktop PC via ethernet
Roon client 2.0 build 1496 64-bit on Windows 11 laptop PC via WiFi
Roon client 2.0 build 1496 on Android 14 via WiFi
Nucleus One server 2.0 build 1496
Note: Throughout these tests, both Windows clients worked fine at all times. Further, the Nucleus One server remained powered on and was not touched.
Log
Day 1
Ran 7-hour burn-in playlist overnight
11:50 - Opened Android tablet. Roon client hung/unresponsive to touch input. Terminated and restated client. Received “Waiting for Server” message.
Touched nothing and just waited (note that I did not reset the server as I had done when I originally posted this issue).
12:02 - Android client became responsive to touch input. Powered on DAC. Received “Uh Oh, Something’s not right” message on Android client. Checked Windows client; all OK. Waited.
12:17 - Without touching Android client, started playback of an album on Windows client. “Uh Oh” message persisted on Android.
12:19 - Without touching Android client, “Uh Oh” message disappeared. Client is now responsive. Stopped playback of album. Waited.
13:15 - Checked Android client via touch input. Responsive.
14:20 - Checked Android client via touch input. Responsive.
15:30 - Checked Android client via touch input. Displays “Waiting for server” message.
17:00 - Checked Android client. Still “Waiting for server” message. Started album playing using Windows client.
17:11 - Checked Android client. Now responsive. Had listening session interacting with Android client without problems.
18:25 - Listening session ended. Android client still OK.
18:40 - Started 7-hour burn-in playlist on Android client.
Day 2
8:10 - Checked Android client. Hung/unresponsive to touch input. Touched nothing else and just waited.
Thank you for your report. I’m assuming that the Roon app was backgrounded, or the screen was locked, during the times the app sat idle in the timeframe above?
The team has a ticket to investigate intermittent server connectivity issues during backgrounding on Android. Diagnostics from the affected Roon GUI on the tablet show that it doesn’t retain a network connection to the RoonServer instance on the Nucleus One after it “wakes up.”
Please allow us a chance to escalate to development and we’ll see what more we can illuminate.
Thanks for the update. I don’t recall backgrounding the app, but I can’t really say for sure that I didn’t. However, there certainly were times when the screen was locked because the tablet just sat idle.
At this point, since it seems that the behavior is somewhat predictable, I can work around it. So, it’s more of an irritant than a pressing issue. Let me know if there’s anything else you’d like me to do to help identify the problem.
The team has a ticket in the pipeline to investigate this behavior further with development. We’ll post here once we have a more illuminating update to share. Thank you!
Curious if there’s any idea on this. Is no one else having this problem? I’d love to know because if it’s only me, I’ll look for something environmental.
The mentioned ticket should have an effect on the underlying mechanism and hopefully resolve the issue in both cases. If you’d like, we can merge this thread into the tracking thread for you to receive more timely updates. Otherwise, we can notify you here as soon as the ticket releases into an Early Access build for testing.
Thanks for the update. The symptoms I’m having are different than in the other thread, but I understand that the problems may be related. It’s good to know so that I don’t go searching for something else. I’ll wait for associated updates. As far as merging the threads, do whatever you think best.
The associated fix is the most efficient A/B test and logic next step, based on the results of our investigation. Unless you’re experiencing freezing or UI symptoms that suggest OneUI 6.1.1 might be involved, then our investigation and incremental fixes to refigure Android client network access after screen lock should help ease this symptom.
We’ll keep this thread separate, however, until we have proof of the cause in this particular case. Thanks for your patience.