Running ROCK on an a NUC6i3SYH and have updated the bios to the latest (61) and running the latest roon build (262) but after being idle for a while when I open the client it cannot connect.
I leave the NUC running 24/7 and have had a look in the bios and the power mode is set to high performance.
What I do find is that if I go to the web interface and restart the roon server software the client immediately connects ok.
Hi @Lebowski ----- Thank you for the report and sharing this observations with us. The insight is appreciated!
Moving forward, at “first glance” it sounds like you may be experiencing the same behavior being reported here. Can you provide the make/model of the remote device you’re experiencing this behavior with and furthermore, can you confirm if any other other remotes are behaving in the same manner, or does this seem isolated to a single device?
-Eric
Client is on my macbook pro
I am seeing this in the log after I just switched on and launched the app on my MacBook…
09/06 18:55:33 Trace: [raat] RAATServer discovered: RaatServer Chriss-MacBook-Pro @ 192.168.111.153:49358
09/06 18:55:33 Info: [raatserver] GOT SERVER 6e3d78c4-95b7-f58d-58a6-6ad7e0fe35fe::df5e524d-b9f2-4102-b03f-3303aa4e4a5f @ 192.168.111.153:49358 Chriss-MacBook-Pro PROTOVER=1 RAATVER=1.1.21
09/06 18:55:33 Trace: [push] restarting connection (Unable to read data from the transport connection: interrupted.)
09/06 18:55:33 Trace: [push] retrying connection in 45835ms
09/06 18:55:33 Trace: [raatserver] [RaatServer Chriss-MacBook-Pro @ 192.168.111.153:49358] connecting (attempt 1)
09/06 18:55:36 Info: [stats] 2493mb Virtual, 410mb Physical, 206mb Managed, 0 Handles, 39 Threads
09/06 18:55:43 Trace: [raatserver] [RaatServer Chriss-MacBook-Pro @ 192.168.111.153:49358] client connection failed. Retrying in 500ms
09/06 18:55:43 Trace: [raatserver] [RaatServer Chriss-MacBook-Pro @ 192.168.111.153:49358] connecting (attempt 2)
09/06 18:55:44 Trace: Successful POST response from https://push.roonlabs.com/push/1/connect
09/06 18:55:44 Trace: [push] connecting to 159.203.179.219:9200
09/06 18:55:44 Trace: [push] connected
09/06 18:55:51 Info: [stats] 2493mb Virtual, 410mb Physical, 207mb Managed, 0 Handles, 39 Threads
09/06 18:55:53 Trace: [raatserver] [RaatServer Chriss-MacBook-Pro @ 192.168.111.153:49358] client connection failed. Retrying in 750ms
09/06 18:55:54 Trace: [raatserver] [RaatServer Chriss-MacBook-Pro @ 192.168.111.153:49358] connecting (attempt 3)
09/06 18:56:04 Trace: [raatserver] [RaatServer Chriss-MacBook-Pro @ 192.168.111.153:49358] client connection failed. Retrying in 1125ms
09/06 18:56:05 Trace: [raatserver] [RaatServer Chriss-MacBook-Pro @ 192.168.111.153:49358] connecting (attempt 4)
09/06 18:56:06 Info: [stats] 2493mb Virtual, 410mb Physical, 207mb Managed, 0 Handles, 38 Threads
09/06 18:56:15 Trace: [raatserver] [RaatServer Chriss-MacBook-Pro @ 192.168.111.153:49358] client connection failed. Retrying in 1687ms
09/06 18:56:17 Trace: [raatserver] [RaatServer Chriss-MacBook-Pro @ 192.168.111.153:49358] connecting (attempt 5)
09/06 18:56:21 Info: [stats] 2493mb Virtual, 410mb Physical, 207mb Managed, 0 Handles, 38 Threads
09/06 18:56:27 Trace: [raatserver] [RaatServer Chriss-MacBook-Pro @ 192.168.111.153:49358] client connection failed. Giving up
09/06 18:56:27 Trace: [raat] [sood] Refreshing device list
09/06 18:56:27 Trace: [push] restarting connection (Unable to read data from the transport connection: interrupted.)
09/06 18:56:27 Trace: [push] retrying connection in 66999ms
And the same when I try to connect with my android phone…
09/06 19:01:43 Trace: [raat] RAATServer discovered: RaatServer TheBig Lebowski's Pixel @ 192.168.111.200:47606
09/06 19:01:43 Info: [raatserver] GOT SERVER f88b46e7-2cb0-2260-dbd8-33277a98f365::f88b46e72cb02260dbd833277a98f365 @ 192.168.111.200:47606 TheBig Lebowski's Pixel PROTOVER=1 RAATVER=1.1.21
09/06 19:01:43 Trace: [raatserver] [RaatServer TheBig Lebowski's Pixel @ 192.168.111.200:47606] connecting (attempt 1)
09/06 19:01:43 Trace: [push] restarting connection (Unable to read data from the transport connection: interrupted.)
09/06 19:01:43 Trace: [push] retrying connection in 16254ms
09/06 19:01:51 Info: [stats] 2493mb Virtual, 410mb Physical, 207mb Managed, 0 Handles, 39 Threads
09/06 19:01:53 Trace: [raatserver] [RaatServer TheBig Lebowski's Pixel @ 192.168.111.200:47606] client connection failed. Retrying in 500ms
09/06 19:01:54 Trace: [raatserver] [RaatServer TheBig Lebowski's Pixel @ 192.168.111.200:47606] connecting (attempt 2)
09/06 19:01:54 Trace: Successful POST response from https://push.roonlabs.com/push/1/connect
09/06 19:01:54 Trace: [push] connecting to 159.203.179.219:9200
09/06 19:01:54 Trace: [push] connected
09/06 19:02:04 Trace: [raatserver] [RaatServer TheBig Lebowski's Pixel @ 192.168.111.200:47606] client connection failed. Retrying in 750ms
09/06 19:02:04 Trace: [raatserver] [RaatServer TheBig Lebowski's Pixel @ 192.168.111.200:47606] connecting (attempt 3)
09/06 19:02:06 Info: [stats] 2493mb Virtual, 410mb Physical, 207mb Managed, 0 Handles, 39 Threads
09/06 19:02:14 Trace: [raatserver] [RaatServer TheBig Lebowski's Pixel @ 192.168.111.200:46360] client connection failed. Retrying in 1125ms
09/06 19:02:15 Trace: [raatserver] [RaatServer TheBig Lebowski's Pixel @ 192.168.111.200:46360] connecting (attempt 4)
09/06 19:02:21 Info: [stats] 2493mb Virtual, 410mb Physical, 207mb Managed, 0 Handles, 38 Threads
09/06 19:02:25 Trace: [raatserver] [RaatServer TheBig Lebowski's Pixel @ 192.168.111.200:46360] client connection failed. Retrying in 1687ms
09/06 19:02:27 Trace: [raatserver] [RaatServer TheBig Lebowski's Pixel @ 192.168.111.200:46360] connecting (attempt 5)
09/06 19:02:36 Info: [stats] 2493mb Virtual, 410mb Physical, 208mb Managed, 0 Handles, 38 Threads
09/06 19:02:37 Trace: [raatserver] [RaatServer TheBig Lebowski's Pixel @ 192.168.111.200:46360] client connection failed. Giving up
09/06 19:02:37 Trace: [push] restarting connection (Unable to read data from the transport connection: interrupted.)
09/06 19:02:37 Trace: [raat] [sood] Refreshing device list
09/06 19:02:37 Trace: [push] retrying connection in 92109ms
09/06 19:02:47 Trace: Successful POST response from https://push.roonlabs.com/push/1/connect
09/06 19:02:47 Trace: [push] connecting to 159.203.179.219:9200
09/06 19:02:47 Trace: [push] connected
09/06 19:02:51 Info: [stats] 2493mb Virtual, 410mb Physical, 208mb Managed, 0 Handles, 40 ThreadsHave just restarted roon server and it connected straight away from macbook and android phone…
09/06 19:05:17 Info: Starting RoonServer v1.3 (build 262) stable on linuxx64
09/06 19:05:23 Trace: [raat] RAATServer discovered: RaatServer Chriss-MacBook-Pro @ 192.168.111.153:49358
09/06 19:05:23 Info: [raatserver] GOT SERVER 6e3d78c4-95b7-f58d-58a6-6ad7e0fe35fe::df5e524d-b9f2-4102-b03f-3303aa4e4a5f @ 192.168.111.153:49358 Chriss-MacBook-Pro PROTOVER=1 RAATVER=1.1.21
09/06 19:05:23 Trace: [raatserver] [RaatServer Chriss-MacBook-Pro @ 192.168.111.153:49358] connecting (attempt 1)
09/06 19:05:23 Trace: [raatserver] [RaatServer Roon Optimized Core Kit @ 127.0.0.1:35063] connectedThanks for the follow up @Lebowski, the insight is very appreciated! So this behavior is occurring on both the MBP and the Pixel C.
Moving forward, I am going to be contacting you via PM with instructions on how to send remote logs from the Pixel C via PM momentarily, as we are currently investigating how android devices are interacting with a Linux core, as mentioned in my previous post.
Furthermore, if you could please fill out our data gathering survey found here, we would greatly appreciate the feedback!
-Eric
Hi @Lebowski — Thank you for the follow up, saw you had completed the survey 
Also confirming that the logs have been received as requested. We’ll let you know what we come up with.
-Eric
@Eric any update on the issue, I now have to restart the roon service on the ROCK a few times before the client on my Macbook is able to connect now…
Hi @Lebowski ---- Thank you for touching base with me and more importantly, thank you for your patience.
I have just checked on the status of your ticket/logs and I see that my report is still with our tech team who are comparing the traces found in your logs, to the logs supplied by others who have reported this behavior. Once they have completed their analysis and have provided me with some concrete feedback, I will be sure to update you promptly.
-Eric
Any update on this as it has been 4 weeks now and I’m getting fed up with having to restart the ROCK everyday just to listen to some music???
Hi @Lebowski ---- Thank you for reaching out, your patience has been appreciated!
I had our techs spend some time revisiting your ticket, logs, and survey answers once more. As you are aware, we’ve been actively gathering data from users who have been reporting remote connectivity issues with Android, and as I’m sure you’re aware we have been working hard but still haven’t been able to pinpoint why some systems seemingly work with a variety of devices and remotes, but have issues specifically with Android Remotes and Linux Cores.
We continue to investigate why 99% of Android remotes work, but certain systems do not, and one of the biggest challenges is separating this issue from more generalized connectivity issues. Obviously, Roon works on tens of thousands of networks, but we field questions about all sorts of connectivity issues, and we need to handle network troubleshooting differently from the more specific Android issue.
The primary symptom of the other issue is that other remotes work (like Windows, OSX, etc) but Android does not. Since you are experiencing this with both your Android remote and your OS X remote, this points to something more generalized. It doesn’t preclude the Android-Linux issue, but at a minimum it points to something all going awry in your environment.
We were hoping the logs would yield a “smoking gun” and we could say ROCK was going unresponsive due to a clear crash, bug, or piece of media, but unfortunately we are not seeing anything in the logs that gives us a clear picture of what’s going on here.
This means our next step is really going to be network troubleshooting. I should be clear that this can take some time, but we do this regularly, and we are almost always able to pinpoint where the problem is, but it can require some patience.
So, you’ve mentioned the following in regard to your network configuration:
“WAN connection into untangle appliance as outside interface (VM DHCP) with inside interface (192.168.111.x) connected to a Cisco 2960G(192.168.111.x). Asus N66u (192.168.111.x) in access point only mode also connected to Untangle and this interface is bridged to the inside interface. All IP addresses are DHCP with the server running on the untangle appliance. Everything sits in vlan 1 on the cisco switch”
This is not the most complex network we’ve seen but it’s also not the simplest. As most people will tell you, the most foolproof way to to determine what could be causing this behavior is process of elimination.
My recommendation would be to remove as much complexity as possible, and confirm that things are stable. I would start with your NUC mounted directly to the mentioned Asus N66U with everything else disabled or moved outside the subnet temporarily.
If things are stable in that configuration, you can add the additional switches, firewall, etc back in one at a time, to verify where things are succeeding and where they are failing.
If things are not stable in a simplified environment, please get back to me with the exact topology and what went wrong, as well as another set of logs – then we can get a better sense of what’s going on here, and start ruling out environmental factors, cables, hardware issues, bugs, etc. I’m sure we can figure this out so thanks in advance for your patience @Lebowski!
-Eric
The Asus is just a WiFi access point but the ROCK and my macbook are cabled to the Cisco switch so there is little point in connecting them to the Asus.
The 2960 is a layer 2 switch so will locally route the traffic between the ROCK and macbook as they are in the same subnet/VLAN and will not go via the router (untangle)
I think Eric was suggesting that you use the Asus to create a subnet and run DHCP for these devices – if ROCK is stable on this very simple network, that’s a good data point for us to know that something in your normal environment is causing ROCK to function differently than we’ve seen elsewhere.
Alternatively, if the issues persist in that setup we’d want to look elsewhere – the hardware, possible software bugs, etc. But seeing if this issue is reproducible in a simpler setup is probably the next step here.
Also, to be clear – we know that re-configuring your network for tests like this is no fun, and we really try not to ask unless we’re out of options.
Had there been something more clear in your logs about this unresponsive state, we could explore other options but for now the best way to get this stable is to rule out environmental factors. Thanks for your patience with this, Chris.
But the communication is going through a single switch, how does it get more simple than that?