Android app having trouble finding Linux Core

Ever since I installed the build 233 version of the Android Roon app (a build 234 one hasn’t made it through the pipeline yet), my phone hasn’t been able to find the Core (which is now at build 234, but this was also the case with build 233); I’m unsure about whether the issue is related to the app upgrade or the core upgrade since they happened pretty much simultaneously, but I may remember having been able to connect to a build 233 RoonServer from a pre-233 Android app.

Build 233 and 234 Mac desktop Roon applications, though, have had no trouble finding the 233 or 234 Core.

RoonServer is on Linux, the phone in question is a Pixel XL running Android 7.1.2.

I’ve tried deleting and re-installing the Roon app, rebooting the phone, stopping and restarting RoonServer, and typing in the IP address of the server.

The app just stays stuck at the “Choose your Core” page.

The app does seem to be reaching the server, though - note some entries in RoonServer_log.txt:

    06/08 01:30:03 Trace: [transport/raat] RAATServer discovered: RaatServer Jeff Moore's Pixel XL @ 10.0.1.220:37264
    06/08 01:30:03 Info: [transport/raatserver] GOT SERVER 8cb9379f-eea8-4661-6f96-fa0985ccdf47::8cb9379feea846616f96fa0985ccdf47 @ 10.0.1.220:37264 Jeff Moore's Pixel XL PROTOVER=1 RAATVER=1.1.19 
    06/08 01:30:03 Trace: [transport/raatserver] [RaatServer Jeff Moore's Pixel XL @ 10.0.1.220:37264] connecting (attempt 1)
    06/08 01:30:03 Trace: [transport/raatserver] [RaatServer Jeff Moore's Pixel XL @ 10.0.1.220:37264] connected
    06/08 01:30:03 Trace: [rnet/RnetJsonClient] SENT {"request":"enumerate_devices","subscription_id":"0"}
    06/08 01:30:04 Warn: Error in web request https://push.roonlabs.com/push/1/connect: NetworkError (The remote server returned an error: (502) Bad Gateway.)
    06/08 01:30:04 Trace: [push] request to manager failed
    06/08 01:30:04 Trace: [push] retrying connection in 2440100ms
    06/08 01:30:04 Trace: [rnet/RnetJsonClient] GOT NONFINAL {"status": "Success", "devices": [{"is_system_output": true, "type": "android", "device_id": "default", "name": "Default Output", "auto_enable": true, "auto_name": "Jeff Moore's Pixel XL"}]}
    06/08 01:30:04 Info: [transport/raatserver] GOT DEVICE 8cb9379feea846616f96fa0985ccdf47::default Type=android Name=Default Output 
    06/08 01:30:13 Info: [stats] 4815mb Virtual, 810mb Physical, 411mb Managed, 0 Handles, 45 Threads
    06/08 01:30:14 Warn: Error in web request https://push.roonlabs.com/push/1/connect: NetworkError (The remote server returned an error: (502) Bad Gateway.)
    06/08 01:30:14 Trace: [push] request to manager failed
    06/08 01:30:14 Trace: [push] retrying connection in 4924580ms
    06/08 01:30:17 Warn: Error in web request https://push.roonlabs.com/push/1/connect: NetworkError (The remote server returned an error: (502) Bad Gateway.)
    06/08 01:30:17 Trace: [push] request to manager failed
    06/08 01:30:17 Trace: [push] retrying connection in 6129075ms
    06/08 01:30:28 Info: [stats] 4815mb Virtual, 810mb Physical, 412mb Managed, 0 Handles, 42 Threads
    06/08 01:30:43 Info: [stats] 4815mb Virtual, 810mb Physical, 412mb Managed, 0 Handles, 41 Threads

I have this same problem, my NUC server is running ROCK all latest updates and recommended hardware, using Samsung Android tablett.

I’m not seeing this issue on the phone running android 7.1.2 (Nexus 6P) with latest build.

Would you mind to reboot your router, machine where Roon core is running ?

@Jeffrey_Moore
@hmartin
@vova

Hello all,

I may not have experienced the same issue, but something similar happened with my Samsung remotes and Mac core.

The issue was resolved by giving RoonServer permission to allow/receive incoming connections.

That’s probably over simplifying it. Hopefully an over-simplified solution will work.

Jeffrey

Thanks for the suggestion! I Think all such firewall configurations should be ok for a ROCK server as it is designed for running RoonServer, and I don’t think an end-user can access any settings anyway.

@vova
I have restarted all devices and the router (Asus RT-AC87U) and the problem persist, thanks!

Edit: Should also say that sometimes the Android tablett finds the Server, seems that rebooting ROCK makes it possible to connect at least once.

On my android (7.1.1) phone, connecting to ROCK (running on a nuc) is shaky, too. Sometimes it works as expected for hours, then I get stuck connecting to the core. Same on my iPad, btw. This started with the 233 update, I didn’t have these problems before.

An update:

After having had no luck in the evening getting the app to control Roon, the next morning I tried it, and… it just connected as normal, and consented to control stuff. I’d made no changes in the meantime, although the phone had had its radios turned off overnight.

Since that was too easy… I killed the app and started it again, to see if it would again connect to Roon.

No dice. The app got stuck at “Waiting for Remote Core…”:

Per the suggestions from @vova, I power-cycled the wireless access point through which the phone connects with our network. After the access point came back up, the Roon app connected to RoonServer. Killed the app and tried again: no connection.

Improbable as its helping seemed, I rebooted the host RoonServer runs on and restarted RoonServer.

The app still can’t connect.

So… yes, it does sometimes succeed in connecting (and I have no idea if this is at all related to whatever I’ve done before or complete coincidence), but most often doesn’t. It doesn’t completely never work, but something about the new versions is way more fragile when it comes to discovering and connecting to Roon than was the case with previous versions.

Update: power-cycled the WiFi access point again. Again, the Android Roon app connected successfully immediately after the AP came back up. It also worked the second time I started the app after killing it. It failed the third time.

Fragile.

1 Like

@hmartin and @Kopftelefon ---- Thank you for chiming in and sharing your experiences after the most recent update.

Moving forward, I would like to have each of you provide the following:

Data Gathering:

  1. A brief but accurate description of your current setup as seen here.

  2. Please outline the details of your network configuration/topology being sure to provide insight into any networking hardware you may be implementing. I want to have a complete understanding of how your devices are communicating and the tools being used to make those connections possible.

  3. Confirm that this is still happening with build 234

Troubleshooting:

  1. Have all devices been power cycled? This includes any networking hardware (i.e. routers, switches, etc).

  2. Have you tried reinstalling the application?

  3. If you have any active firewalls or antivirus application running, please temporarily disable them and confirm if you are still noticing the issue.

-Eric

Hello @Eric,

All connection problems happened with build 233/234.

Since I posted in this thread, my android remote is behaving perfectly, without any of the onnection problems I had before. On my iPad, I had to reinstall the app in order to make it work again (multiple power cycles didn’t work), but that seems to have solved the problem, too, at least for now.

I’ll keep an eye on it and will keep you posted, should I have further troubles.

Edit:
I forgot to mention that I switched off standby and hibernation for the roon remote app in android battery settings. Don’t know if it’s important, though.

@Eric I understand the good intent of your standard troubleshooting instructions, but for many of us they are impractical, especially power-cycling all devices. Just power-cycling my NAS properly takes several minutes. In this specific case, nothing in my network, wireless access points, servers, switches, or clients has changed in several months, and yet my Pixel phone has stopped finding my Roon Core since 233. My iPad and my Mac find the same core perfectly. Rather than generic instructions, I’d appreciate a specific debugging protocol for core connection attempts. For example, when I try to connect from my Pixel (latest Roon Remote app, latest Android), my Roon Core log says the stuff below. What else do you want to debug the issue?

06/09 19:38:03 Trace: [transport/raat] RAATServer discovered: RaatServer Fernando Pereira's Pixel @ 192.168.2.69:44735
06/09 19:38:03 Info: [transport/raatserver] GOT SERVER d3577b51-4675-7ac0-b9e1-90887f60d28c::d3577b5146757ac0b9e190887f60d28c @ 192.168.2.69:44735 Fernando Pereira's Pixel PROTOVER=1 RAATVER=1.1.19 
06/09 19:38:03 Trace: [transport/raatserver] [RaatServer Fernando Pereira's Pixel @ 192.168.2.69:44735] connecting (attempt 1)
06/09 19:38:03 Trace: [transport/raatserver] [RaatServer Fernando Pereira's Pixel @ 192.168.2.69:44735] connected
06/09 19:38:03 Trace: [rnet/RnetJsonClient] SENT {"request":"enumerate_devices","subscription_id":"0"}
06/09 19:38:03 Trace: [rnet/RnetJsonClient] GOT NONFINAL {"status": "Success", "devices": [{"auto_name": "Fernando Pereira's Pixel", "is_system_output": true, "device_id": "default", "type": "android", "name": "Default Output", "auto_enable": true}]}
06/09 19:38:03 Info: [transport/raatserver] GOT DEVICE d3577b5146757ac0b9e190887f60d28c::default Type=android Name=Default Output 
06/09 19:38:10 Info: [stats] 2494mb Virtual, 426mb Physical, 193mb Managed, 0 Handles, 36 Threads
06/09 19:38:13 Warn: Error in web request https://push.roonlabs.com/push/1/connect: NetworkError (The remote server returned an error: (502) Bad Gateway.)
06/09 19:38:13 Trace: [push] request to manager failed
06/09 19:38:13 Trace: [push] retrying connection in 161238ms
06/09 19:38:25 Info: [stats] 2494mb Virtual, 426mb Physical, 193mb Managed, 0 Handles, 36 Threads
06/09 19:38:40 Info: [stats] 2494mb Virtual, 426mb Physical, 193mb Managed, 0 Handles, 33 Threads
06/09 19:38:55 Info: [stats] 2494mb Virtual, 426mb Physical, 193mb Managed, 0 Handles, 36 Threads
06/09 19:39:10 Info: [stats] 2494mb Virtual, 426mb Physical, 193mb Managed, 0 Handles, 33 Threads
06/09 19:39:25 Info: [stats] 2494mb Virtual, 426mb Physical, 193mb Managed, 0 Handles, 35 Threads
06/09 19:39:32 Warn: Error in web request https://push.roonlabs.com/push/1/connect: NetworkError (The remote server returned an error: (502) Bad Gateway.)
06/09 19:39:32 Trace: [push] request to manager failed
06/09 19:39:32 Trace: [push] retrying connection in 89308ms
1 Like
  1. ROCK 6i5 + USB drive --> Ethernet --> Asus AC87 --> wifi --> Samsung

  2. Nothing additional

  3. Yes

  4. Yes

  5. The Roon Remote but not ROCK nor Roon server

  6. No. Rock has no firewall (?) and Asus has only one towards internet

I’ve reinstalled Roon Remote several times and rebooted my Pixel phone (up to date Android software). Can’t still find Roon Core. The only thing that changed significantly on my network is the update to Roon 233/234. Rest of (Stable) configuration:

Core on Ubuntu 16.04.1 NUC
Ubiquiti UniFi Pro AP WiFi, PoE-powered from
Ubiquiti EdgeRouter PoE-5 router
Wired network fabric connecting all of the above and more is Cat 6 with a couple of Netgear ProSAFE Plus switches

As noted, all of these have unchanged since well before the 233 Roon update. The only strict firewall in the system is in the EdgeRouter between my LAN and the cable modem, which is on a separate router interface and IP network. The Ubuntu firewalls on the NUC (IPv4 and IBv6) are disabled.

I’m happy to run detailed network diagnostics this weekend if you tell me what would help.

The plot thickens. This problem is Android version dependent. I have an older Android device around that I had not been using for a while (Nexus 7 2013 tablet that I forgot on a long-distance United flight, was found several months later, and recently returned by United). I just updated Roon Remote to 233 on this device, and it works perfectly. The tablet has Android 6.0.1, while my Pixel is on 7.1.2. I guess I’ll recruit the Nexus 7 to Roon Remote duty (after all, it was sitting on the shelf because I bought an iPad to replace it when I thought it was lost for good) and wait to see what happens on this thread. Still happy to help with diagnostics if there’s some specific logs (Roon or networking data) that would help.

Did you try switching off standby for the remote in android battery settings on your pixel phone?
If I’m not mistaken, this function is not implemented in android 6. Switching it off for roon seems to have solved all my problems I had previously.

The iPad app is a complete covfefe atm though, but that’s for another thread.

EDIT:
I was mistaken. Doze mode came with android 6. You may give it a shot anyway…

1 Like

Good call! In Android 7, the setting is under Settings>Battery>Battery Optimization>All apps>Roon Remote, where you can turn off battery optimization. I had tried this yesterday, but somehow it did not work. Retried it now, bingo!

I don’t see the problem in Android 6 (Nexus 7), even though I’ve not tweaked anything there.

1 Like

Thanks! No problems since disabling the battery optimization. :slight_smile:

Actually thought I had done that already but did a full reset of the Samsung tablett when I hade the “Cannot load large albums bug”.

Edit: My Samsung is Android 6.0.1 btw so it is not only Android 7.

Back to square one. Both Pixel (Android 7) and Nexus 7 (Android 6) fail to connect to the core after sleeping. Stopping and restarting Roon Remote does not help. iPad and Macbook connect fine. Something has definitely gone awry with core (re)discovery after sleep for Android Roon Remote.

1 Like

Hey @Fernando_Pereira and others. We’ve done a good deal of testing on Android leading up to this release, and there’s been no Android specific work in Build 233 (234 is Core only).

That said, there are hundreds of possible environmental variables here, and we’re going do some additional testing in house to see if we can reproduce the symptoms described in this thread.

As for other next steps, @Eric is going to follow up and try to gather some logs from your devices. If you are using any kind of even-vaguely-exotic network configuration (hardware firewall, mesh networks, EoP, “bridge mode”, etc), I would recommend experimenting with a simple DHCP router/ethernet/wifi setup, and seeing if you can modulate the problem.

This isn’t to push QA or testing onto you guys – we have a lot of gear in house for testing but we can’t test every setup. If we can narrow this done to a certain configuration or device that causes this issue, it’s that much more likely we can reproduce in house, and resolve it.

Thanks for your patience guys – we’re on it and I’m confident we can figure out what’s going on here.

1 Like

@mike thank you for digging into this! My configuration is straightforward: single wired router providing DHCP to all devices; fixed devices have static IPs assigned by the router; wifi AP connected to router with Cat 6, getting routing and address assignments from router (both made by Ubiquiti); Netgear switch between router and NUC running Core; mobile devices have DHCP-assigned IPs; none of this changed in the last 6 months; Android devices that can’t connect to Core still talk to everything else via the same wifi AP; iPad and MacBook don’t have the problem. Happy to provide any logs that would help.

I’ve had the system send a support package to @Eric tagged with the support ID he gave me directly. I wasn’t able to do this via the Android device which is misbehaving - the connection between client and Core won’t pretend to stay up for long enough for that - so I guess there can’t be any logs from the Android side; but I’m hoping you’ll at least be able to see what’s been going on on the server side (for clients which work as well as don’t work).

I’ve also provided him with exact network hardware involved - in short, it involves an Asus WiFi access point (which is not being used as a router) and then hardwired everything to the server, a path which is still working fine for a Mac laptop running desktop Roon.

Inside the house, the network is flat, with wireless devices being assigned IPs by DHCP on the wired router which is there on the network but isn’t actually on the direct bath between Roon clients and server - the router would only be traversed by traffic out to the public Internet.