Android Roon Remote looses connection to Core (daily)

Support
1

Hello,

After some weeks of using a Roon Remote on my Android phone, the Roon Remote regularilly stops being able to find the Roon core. :thinking:

  1. Environment description:
  • I have a Roon core running on a Linux Server.
  • There is a single flat network topology (192.168.0.0/24), shared by all ethernet connections and one single wireless AP.
  • There is only one central switch, the endpoints and the WLAN AP connect to it.
  • A Windows 10 Roon install (in remote mode): via ethernet
  • A Ropieee endpoint: via ethernet
  • Various Squeezebox endpoints: via ethernet
  • An Android remote: via WLAN
  1. Description of normal function:
  • Yes, everything has already worked, this is not an initial setup issue.
  • The configurations of the Roon core, the Linux server, the Switch and the AP, and the Android phone have not changed.
  1. Problem description:
  • The android Roon remote stops working after about a day. It works, then it can no longer connect to (does not find) the core.
  • The various endpoints and the windows remote continue to function when the android remote has stopped to do so.

  1. A workaround solution:
    Restarting the Roon core (systemd service) (the Linux server itself is not touched nor is the server restarted) fixes the issue with the android remote. The android remote then immediately finds and connects to the core. The solution does not last more than a day: then, restarting the Roon core again fixes the issue.

  2. Repeatability:
    Always.

  3. Discussion:

  • It doesn’t seem to be a firewall issue, because the other Roon components continue to work, and the issue can be solved (for a day) by restarting just the roon core service.
  • Since neither the AP config, other networking components, nor the Linux server, nor the roon core configuration have been changed.
  • The android phone hasn’t been restarted, only the core service on the Linux server has been restarted, and then the android endpoint is able to connect to the core.
  • The AP hasn’t been touched, so the WLAN connection from the the android phone to the AP, and the IP connection via the AP <-> switch <-> Linux server are continuous - only the roon core service has been restarted, which solves the issue immediately.

Hence it doesn’t seem to be a networking issue.

  1. Details:
  • Android environment:
    Remote Roon Version1.6 (Build 390) Stable (32bit)
    Android 6.0.1
    Kernel 3.10.84-perf-g6581bdb ec_agent@br60cnc #1 Tue Oct 17 19:37:10 EDT 2017
  • Linux environment:
    Core Roon Version 1.6 (build 390) stable (64bit)
    CentOS Linux release 7.6.1810
    Linux 3.10.0-957.5.1.el7.x86_64 #1 SMP Fri Feb 1 14:54:57 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
    nodejs-6.16.0-1.el7.x86_64

And just for good measure, the iptables setup: :wink:

# iptables -n -L | grep -e INPUT -e source -e 9003 -e 9100
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  192.168.0.0/24       0.0.0.0/0            udp dpt:9003
ACCEPT     tcp  --  192.168.0.0/24       0.0.0.0/0            multiport dports 9100:9200

I’m here to provide any information you need to solve the issue.

Sincerely

Chris

3

There are several threads that may be relevant, including this very long one

In summary, the only specific workaround that seems to have worked for multiple users (including me) is to make sure IGMP snooping is turned off if using a configurable switch.

4

Hello,

I am aware of that discussion, which pointed to a network issue.

  • The switch does not have IGMP snooping configured.
  • I don’t see a networking issue (which I was at pains to document.)

-Chris

5

My setup did not show a network issue either on the kinds of tests you reported, but still turning off IGMP snooping fixed the problem, although other thinks changed too in close proximity, including switch firmware, so that might have been a coincidence. It looks like that there’s still a subtle, hard to replicate issue where a Linux-based Room core “decides” that an Android endpoint is unreachable and stops trying to reach it. The problem seems to go away with some changes in network configuration, firmware, or Android version.

6

Hi Fernando,

The switch does not have IGMP snooping enabled. :wink:

The Roon remote on the Android phone is able to connect to the Roon core just fine! No config changes of any sort, not on the Linux server, the Roon core config, the switch, the AP, nor on the Android phone are required to get everything to work just fine. -> Provided that the Roon core (on the Linux server via systemd service) has been freshly re-started.

Further testing results:

  • After regular (daily) errors, I can now better define the time it takes for the Android Roon remote to fail to connect to the core as less than 12 hours (over night) since Roon core restart.
  • Testing will be expanded to a Roon remote installed on different Android phone (of a completely different make, model, and Android version) to compare results.
  • If Roon support is reading this (this is self-help here, right? Meaning to get official help, you have to contact Roon some how?), I can do a packet trace on the traffic between the Roon core and the Android phone. It’d be of great help if someone told me what to look for, or better yet, where I can send the data for analysis.

-Chris

7

You need to tag @support for Roon support to follow up, just done that :slight_smile: The symptoms you describe are exactly the ones I experienced for months before the change in my network solved the issue. If you look at your Roon Core logs carefully, you’ll find that the problem is that after the 12 hours or so, the Core stops “seeing” the phone. Here’s the tail end of my logs:

02/11 03:47:55 Trace: [raatserver] [RaatServer Pixel 3 XL @ 192.168.2.89:42801] connected
02/11 03:47:55 Trace: [rnet/RnetJsonClient] GOT NONFINAL {"status": "Success", "devices": [{"is_system_output": true, "device_id": "default", "type": "android", "name": "Default Output", "auto_enable": true, "auto_name": "Pixel 3 XL", "config": {"unique_id": "60603f60-a1be-e839-0afe-58140fe37c3d", "volume": {"type": "android", "device": "default"}, "output": {"type": "android", "device": "default", "name": "Default Output", "max_bits_per_sample": 16}, "external_config": {"is_private": true, "max_bits_per_sample": 16, "max_sample_rate_multiplier": 1}}}]}
02/11 03:47:55 Trace: [rnet/RnetJsonClient] GOT NONFINAL {"status": "DeviceChanged", "device": {"is_system_output": true, "device_id": "default", "discovery_data": {"version": "N/A", "raat_version": "1.1.33", "tcp_port": 40153, "unique_id": "60603f60-a1be-e839-0afe-58140fe37c3d", "protocol_version": "3", "model": "N/A", "vendor": "N/A"}, "type": "android", "name": "Default Output", "auto_enable": true, "auto_name": "Pixel 3 XL", "config": {"unique_id": "60603f60-a1be-e839-0afe-58140fe37c3d", "volume": {"type": "android", "device": "default"}, "output": {"type": "android", "device": "default", "name": "Default Output", "max_bits_per_sample": 16}, "external_config": {"is_private": true, "max_bits_per_sample": 16, "max_sample_rate_multiplier": 1}}}}
02/11 04:11:05 Trace: [raatserver] [RaatServer Pixel 3 XL @ 192.168.2.89:42801] lost client connection. Retrying
02/11 04:11:05 Trace: [raatserver] [RaatServer Pixel 3 XL @ 192.168.2.89:42801] connecting (attempt 1)
02/11 04:11:05 Trace: [raatserver] [RaatServer Pixel 3 XL @ 192.168.2.89:42801] client connection failed. Retrying in 500ms
02/11 04:11:05 Trace: [raatserver] [RaatServer Pixel 3 XL @ 192.168.2.89:42801] connecting (attempt 2)
02/11 04:11:05 Trace: [raatserver] [RaatServer Pixel 3 XL @ 192.168.2.89:42801] client connection failed. Retrying in 750ms
02/11 04:11:06 Trace: [raatserver] [RaatServer Pixel 3 XL @ 192.168.2.89:42801] connecting (attempt 3)
02/11 04:11:06 Trace: [raatserver] [RaatServer Pixel 3 XL @ 192.168.2.89:42801] client connection failed. Retrying in 1125ms
02/11 04:11:07 Trace: [raatserver] [RaatServer Pixel 3 XL @ 192.168.2.89:42801] connecting (attempt 4)
02/11 04:11:07 Trace: [raatserver] [RaatServer Pixel 3 XL @ 192.168.2.89:42801] client connection failed. Retrying in 1687ms
02/11 04:11:09 Trace: [raatserver] [RaatServer Pixel 3 XL @ 192.168.2.89:42801] connecting (attempt 5)
02/11 04:11:09 Trace: [raatserver] [RaatServer Pixel 3 XL @ 192.168.2.89:42801] client connection failed. Giving up

The “Giving up” you see that the bottom is what happens, but unlike on my system, there’s no later recovery. The long-standing suspicion is that there’s something wonky in how multicast-based discovery is being used by Roon on Linux and Android, but after much debugging, including having the Roon engineers on my LAN tracing packets, nothing conclusive resulted. Then the network changes I told you about, and the problem has been gone for over one year…

8

Hi Fernando,

thanks for the detailed info.

I have a Cisco SG300 switch running in layer 2 (I’m an IT engineer, so I have pro gear… comes with the territory), and it definitely does not have IGMP snooping enabled. You mention multicast - aha! I see that I need to read more about RAAT and exactly how Roon networking functions, I was going at this as if it were plug-and-play, but that was a bit naive of me.

What I can do is bypass the switch entirely and connect the wireless AP directly to an interface on the CentOS server where the Roon core is running - can’t get any more direct than that. Same goes for anything else that could be tested, creating a two-component setup with no active networking components in between.

Roon is not Squeezebox, yet I am at this point forced to compare the two, and remark that 15 years of Squeezebox worked absolutely stably in any wired or wireless topology that it happened to be running on (the last 5 years with the same network that Roon is tripping over for the last three weeks.) I can only hope Roon gets to be as bomb-proof as the Squeezeboxen.

Again, thanks for the details.

-Chris

9

And here it is, as you said Fernando:

02/11 16:24:59 Trace: [raat] RAATServer discovered: RaatServer STV100-1 @ 192.168.0.205:39055
02/11 16:24:59 Info: [raatserver] GOT SERVER 8bc841a2-a51e-381d-ee84-ad3dda0bd93e::8bc841a2a51e381dee84ad3dda0bd93e @ 192.168.0.205:39055 STV100-1 PROTOVER=1 RAATVER=1.1.33 
02/11 16:24:59 Trace: [raatserver] [RaatServer STV100-1 @ 192.168.0.205:39055] connecting (attempt 1)
02/11 16:24:59 Trace: [raatserver] [RaatServer STV100-1 @ 192.168.0.205:39055] connected
02/11 16:24:59 Trace: [rnet/RnetJsonClient] GOT NONFINAL {"status": "Success", "devices": [{"device_id": "default", "auto_name": "STV100-1", "type": "android", "auto_enable": true, "name": "Default Output", "is_system_output": true, "config": {"unique_id": "659025dc-d031-607f-b03c-d962cf0c8b48", "output": {"name": "Default Output", "max_bits_per_sample": 16, "type": "android", "device": "default"}, "external_config": {"is_private": true, "max_bits_per_sample": 16, "max_sample_rate_multiplier": 1}, "volume": {"type": "android", "device": "default"}}}]}
02/11 16:24:59 Trace: [rnet/RnetJsonClient] GOT NONFINAL {"status": "DeviceChanged", "device": {"device_id": "default", "auto_name": "STV100-1", "type": "android", "discovery_data": {"unique_id": "659025dc-d031-607f-b03c-d962cf0c8b48", "tcp_port": 46059, "version": "N/A", "raat_version": "1.1.33", "protocol_version": "3", "model": "N/A", "vendor": "N/A"}, "auto_enable": true, "name": "Default Output", "is_system_output": true, "config": {"unique_id": "659025dc-d031-607f-b03c-d962cf0c8b48", "output": {"name": "Default Output", "max_bits_per_sample": 16, "type": "android", "device": "default"}, "external_config": {"is_private": true, "max_bits_per_sample": 16, "max_sample_rate_multiplier": 1}, "volume": {"type": "android", "device": "default"}}}}
02/11 16:25:00 Trace: [zone STV100-1] Loading
02/11 16:25:00 Trace: [zone STV100-1] Suspend
02/11 16:25:00 Trace: [STV100-1] [zoneplayer/raat] Endpoint Default Output Initial State: Idle
02/11 16:25:00 Info: [transport] created zone STV100-1
02/11 16:25:00 Trace: [STV100-1] [Inactive] [STOPPED @ 0:00] 
02/11 16:25:00 Trace: [roonapi] [apiclient 127.0.0.1:42498] CONTINUE Changed {"zones_added":[{"zone_id":"1601dc25906531d07f60b03cd962cf0c8b48","display_name":"STV100-1","outputs":[{"output_id":"1701dc25906531d07f60b03cd962cf0c8b48","zone_id":"1601dc25906531d07f60b03cd962cf0c8b48","can_group_with_output_ids":[],"display_name":"STV100-1","source_controls":[{"control_key":"1","display_name":"Default Output","supports_standby":false,"status":"indeterminate"}]}],"state":"stopped","is_next_allowed":true,"is_previous_allowed":true,"is_pause_allowed":false,"is_play_allowed":true,"is_seek_allowed":false,"queue_items_remaining":1,"queue_time_remaining":271,"settings":{"loop":"disabled","shuffle":false,"auto_radio":true},"now_playing":{"seek_position":null,"length":271,"one_line":{"line1":"Old Money - Lana Del Rey"},"two_line":{"line1":"Old Money","line2":"Lana Del Rey"},"three_line":{"line1":"Old Money","line2":"Lana Del Rey","line3":"Ultraviolence"},"image_key":"84e3bdd0188d1b58401f0584efa2da5e","artist_image_keys":["9d81c1f3a10accba791f7d610fe42d83"]}}]}
02/11 16:25:00 Trace: [zone STV100-1] Loaded Queue=440 Tracks Swim=Active AutoSwim=True Loop=Disabled Shuffle=False
02/11 16:25:00 Trace: [STV100-1] [Inactive] [PAUSED @ 1:49/4:31] Old Money - Lana Del Rey
02/11 16:29:34 Trace: [raatserver] [RaatServer STV100-1 @ 192.168.0.205:39055] lost client connection. Retrying
02/11 16:29:34 Trace: [raatserver] [RaatServer STV100-1 @ 192.168.0.205:39055] connecting (attempt 1)
02/11 16:29:34 Info: [transport] destroyed zone STV100-1 was playing? False
02/11 16:29:34 Trace: [zone STV100-1] Suspend
02/11 16:29:44 Trace: [raatserver] [RaatServer STV100-1 @ 192.168.0.205:39055] client connection failed. Retrying in 500ms
02/11 16:29:45 Trace: [raatserver] [RaatServer STV100-1 @ 192.168.0.205:39055] connecting (attempt 2)
02/11 16:29:55 Trace: [raatserver] [RaatServer STV100-1 @ 192.168.0.205:39055] client connection failed. Retrying in 750ms
02/11 16:29:55 Trace: [raatserver] [RaatServer STV100-1 @ 192.168.0.205:39055] connecting (attempt 3)
02/11 16:30:05 Trace: [raatserver] [RaatServer STV100-1 @ 192.168.0.205:39055] client connection failed. Retrying in 1125ms
02/11 16:30:07 Trace: [raatserver] [RaatServer STV100-1 @ 192.168.0.205:39055] connecting (attempt 4)
02/11 16:30:17 Trace: [raatserver] [RaatServer STV100-1 @ 192.168.0.205:39055] client connection failed. Retrying in 1687ms
02/11 16:30:18 Trace: [raatserver] [RaatServer STV100-1 @ 192.168.0.205:39055] connecting (attempt 5)
02/11 16:30:28 Trace: [raatserver] [RaatServer STV100-1 @ 192.168.0.205:39055] client connection failed. Giving up

This is very interesting, because you can see that the Android (device name STV100-1) Roon remote was CONNECTED to the core at 16:24:59, and then is “Inactive” at 16:25:00, then 16:29:34 the connection is lost, and by 16:30:28 the core gives up.

To be clear: I was sitting in my living room this entire time, I didn’t lose Wifi during this time.

Now, hours later, the connection does of course not work anymore. Restarting the core Linux service fixes it for another 12 hours or so.

-Chris

10

Hello @CRo,

Thanks for contacting with us regarding this issue.

We have seen this issue before with Linux based Core and Android remotes and the solution for a majority of users was to disable IGMP snooping as Fernando has mentioned, but since you do not have this option it will be a much trickier to narrow down where exactly multicast is going wrong in your setup.

There has been quite a lengthy discussion regarding this issue which you can read about in the thread Fernando linked above, a few Roon team members also chimed in including in this post by Mike and we have repeatedly tried to reproduce this issue on our end without success.

Although it is not ideal, we have found that this connectivity issue mainly affects Linux based Cores and Android based Remotes, so if you’re willing to make the switch to a Windows or OSX core, it should help significantly in alleviating the issue. If you plan on troubleshooting this issue further on Linux and are able to successfully find out where multicast is going wrong, please do let us know as we would love to have more information as to what exactly causes it.

Thanks,
Noris

11

Hi Noris,

When I was helping debug this issue unsuccessfully back when, one thing I commented on then was that it seemed to be associated with the RAAT side of the Android Roon app, that is, the side that has to do with using Android as an endpoint, that is, with the Core trying to check that the Android app is available to play music. However, most of us use Android remotes just as controls, not as endpoints. Did you consider providing a way to disable the RAAT (endpoint) side of the Android app to see if that fixes the problem? I think I suggested this back then.

12

Hello Noris and Fernando,

Sadly (I say that with irony), being a Linux engineer makes me want to use Windows as a desktop and Linux as a server. :wink: I suppose I could run Windows in a KVM VM on the Linux server, just for Roon core, but… ehm… that’s not a proper solution. A crontab entry restarting the core every 12 hours is also not ideal, but I’m leaning toward that right now.

But let’s find out what the deal is and fix it properly. The point that the Core tries to check the ability of the Android device to stream (which it can’t anyway, but I suppose it waits to actually get that response and if doesn’t, it times out, as you mentioned Fernando) seems like something that could be corrected.

In the mean time I have added a second Android device just for testing the problem - it doesn’t have cell connectivity, just wifi, and it has the same problem (as was to be expected).

The Cisco SG300 can also run in Layer 3 (which makes it essentially a switch-router) and can do DPI. That might be a way of seeing what multicast is doing better. Also on the Linux server I could do tcpdumps. That generates too much data to run all day long, pinpointing when (12 hours… about or exactly?) the problem starts is helpful.

-Chris

13

Sorry to chip in. Would it make any difference if you set the android off streaming roon to see if that keeps the connection live. Might give some different diagnostics?

14

Hi, I think I know the least about Roon in this thread – you guys tell me how to do that, and I’ll try it out. :slight_smile:

-Chris

15

You have the roon client on the phone, it can be an end point as well as control. Go to settings, audio on the server and you should see the phones as endpoints, give them a name and off you go.

16

Hi,

OK.

Looking at the two Androids:
Android Client 1: Settings: Audio: Default Output was enabled - Device listed as connected to core.*
Android Client 2: Settings: Audio: Default Output was not enabled (!) - Device was not listed on the core.

*Both devices did not connect until core was restarted (#systemctl restart roonserver).

-Chris

17

So rather than just using them as remotes start a stream to one and see if it stays connected?

18

Howdy,

it didn’t make a difference.
Tested were two Android devices connected via Wifi.
One has Roon without streaming enabled.
One has Roon with streaming enabled.

Both were not able to connect to the core after some time had past since last core restart.

Here’s the new (well it’s quite old, new to the test though) Android. I tailed the roon logfile (meaning I watched in realtime as lines were added) and started the roon client.

02/13 22:49:33 Trace: [raat] RAATServer discovered: RaatServer SM-N9005 @ 192.168.0.228:59900
02/13 22:49:33 Info: [raatserver] GOT SERVER 0f466c0a-4b03-43e7-ec95-7b30d885898f::0f466c0a4b0343e7ec957b30d885898f @ 192.168.0.228:5990
0 SM-N9005 PROTOVER=1 RAATVER=1.1.33 
02/13 22:49:33 Trace: [push] restarting connection (Unable to read data from the transport connection: interrupted.)
02/13 22:49:33 Trace: [raatserver] [RaatServer SM-N9005 @ 192.168.0.228:59900] connecting (attempt 1)
02/13 22:49:33 Trace: [push] retrying connection in 49796ms
02/13 22:49:33 Trace: [raatserver] [RaatServer SM-N9005 @ 192.168.0.228:59900] connected
02/13 22:49:33 Trace: [rnet/RnetJsonClient] SENT {"request":"enumerate_devices","subscription_id":"0"}
02/13 22:49:33 Trace: [rnet/RnetJsonClient] GOT NONFINAL {"status": "Success", "devices": [{"auto_name": "SM-N9005", "type": "android", 
"device_id": "default", "config": {"unique_id": "d16f702b-b970-e304-b72e-3e5fef8b044e", "output": {"device": "default", "type": "android
", "max_bits_per_sample": 16, "name": "Default Output"}, "external_config": {"max_sample_rate_multiplier": 1, "is_private": true, "max_bits_per_sample": 16}, "volume": {"device": "default", "type": "android"}}, "name": "Default Output", "auto_enable": true, "is_system_output": true}]}
02/13 22:49:33 Info: [raatserver] GOT DEVICE 0f466c0a4b0343e7ec957b30d885898f::default Type=android Name=Default Output 
02/13 22:52:10 Trace: [raatserver] [RaatServer SM-N9005 @ 192.168.0.228:59900] lost client connection. Retrying
02/13 22:52:10 Trace: [raatserver] [RaatServer SM-N9005 @ 192.168.0.228:59900] connecting (attempt 1)
02/13 22:52:10 Warn: [rnet/RnetJsonClient] failed to connect Connection refused
02/13 22:52:10 Trace: [raatserver] [RaatServer SM-N9005 @ 192.168.0.228:59900] client connection failed. Retrying in 500ms
02/13 22:52:11 Trace: [raatserver] [RaatServer SM-N9005 @ 192.168.0.228:59900] connecting (attempt 2)
02/13 22:52:11 Warn: [rnet/RnetJsonClient] failed to connect Connection refused
02/13 22:52:11 Trace: [raatserver] [RaatServer SM-N9005 @ 192.168.0.228:59900] client connection failed. Retrying in 750ms
02/13 22:52:12 Trace: [raatserver] [RaatServer SM-N9005 @ 192.168.0.228:58736] connecting (attempt 3)
02/13 22:52:12 Trace: [raatserver] [RaatServer SM-N9005 @ 192.168.0.228:58736] connected
02/13 22:52:12 Trace: [rnet/RnetJsonClient] SENT {"request":"enumerate_devices","subscription_id":"0"}
02/13 22:52:12 Trace: [rnet/RnetJsonClient] GOT NONFINAL {"status": "Success", "devices": [{"device_id": "default", "is_system_output": true, "type": "android", "name": "Default Output", "auto_enable": true, "auto_name": "SM-N9005", "config": {"output": {"type": "android", "name": "Default Output", "device": "default", "max_bits_per_sample": 16}, "unique_id": "d16f702b-b970-e304-b72e-3e5fef8b044e", "external_config": {"is_private": true, "max_bits_per_sample": 16, "max_sample_rate_multiplier": 1}, "volume": {"type": "android", "device": "default"}}}]}
02/13 22:52:12 Info: [raatserver] GOT DEVICE 0f466c0a4b0343e7ec957b30d885898f::default Type=android Name=Default Output 
02/13 22:52:12 Trace: [push] restarting connection (Unable to read data from the transport connection: interrupted.)
02/13 22:52:12 Trace: [push] retrying connection in 86721ms

Reading that, it would seem the connection is there. It discovers the Android device, says the connection is interrupted, then retries and makes a connection, status is Success.

[rnet/RnetJsonClient] GOT NONFINAL {“status”: “Success”, “devices”: [{“device_id”: “default”, “is_system_output”: true, “type”: “android”, “name”: “Default Output”, “auto_enable”: true, “auto_name”: “SM-N9005”, “config”:

But no dice. The roon client doesn’t get past “Waiting for remote core”.

-Chris

19

Hi @CRo,

Thanks for performing that test. I have gone ahead and enabled diagnostics mode for your account and what this action will do is next time your Core and Remote is active, a set of logs will automatically be generated and uploaded to our servers for analysis.

I have scheduled a meeting with a team to discuss this case, I will be sure to let you know as soon as I have any additional feedback for you here. If you are able to make any progress on your end please do let me know so that I can include it in our discussion.

Thanks,
Noris

20

Hello @Noris,

super!

So, this morning you should see the two Android devices failing to connect. You can also see a Dietpi device with Hifiberry DAC connecting and playing properly.

What I’ll do after I hear back from you, is to restart the roonserver core service on the CentOS 7 server, and then re-connect with the Androids, so you can see successful connects as well.

To document the IGMP settings better, a screenshot:

sg300_igmp1
sg300_igmp1.jpg1125Ă—356 173 KB

So, the SG300 is a small business layer 2 and 3 switch that has a ton of IGMP settings beyond just “snooping”. But they are all off - no snooping, querier, vlans, groups, etc… We could in fact try doing something with this, but ofcourse, I think the goal is to make roon work for anyone, not just folks with switches that have have too many bells and whistles. :grimacing:

But I am quite happy testing stuff that you want to see, on Linux and in general.

-Chris

21

Hi @CRo,

Thank you for providing that information, I have discussed your case with the team and we would need some more information to proceed here, can you please let me know:

  • What exactly do you see on your Android screen when this issue occurs? Can you please post a screenshot or two?
  • Can you confirm that simply restarting the Android app does not help?
  • In a similar regard, does rebooting the Android device help?
  • I’d like to gather a few sets of logs here as we proceed through some of these tests.
    If you’re open to working with us on this, I’ll send you some next steps over PM

Thanks,
Noris