Network Reachability Changed, Immediate Out of Memory Crash

Roon Core Machine

Dedicated MacBookPro (nothing else running except system and RoonCore)
Ubuntu 22.04
3.5 GHz Dual-Core i7
16 GB RAM

Core: Roon 2.0 (1133)

Networking Gear & Setup Details

Ethernet between RoonCore and Cambridge

Connected Audio Devices

Streaming via Cambridge Audio 851N, connected to Core via ethernet (through TP switch)

Number of Tracks in Library

~60k

Description of Issue

I’m receiving the following notice in logs about every 30 seconds or so:

11/23 10:10:55 Trace: [remoting/brokerserver] network reachability changed. Kicking off discovery cycle
11/23 10:11:15 Trace: [broker/accounts] network reachability changed. refreshing
11/23 10:11:15 Debug: [tidal] network reachability changed. refreshing token
11/23 10:11:15 Trace: [mobile] [remoteconnectivity] Port Verification started due to: network reachability changed, port verification not in progress, starting a new attempt
11/23 10:11:15 Trace: [roonapi] network reachability changed. Kicking off discovery cycle
11/23 10:11:17 Trace: [remoting/brokerserver] network reachability changed. Kicking off discovery cycle
11/23 10:11:37 Trace: [broker/accounts] network reachability changed. refreshing
11/23 10:11:37 Debug: [tidal] network reachability changed. refreshing token
11/23 10:11:37 Trace: [mobile] [remoteconnectivity] Port Verification started due to: network reachability changed, port verification not in progress, starting a new attempt
11/23 10:11:37 Trace: [roonapi] network reachability changed. Kicking off discovery cycle
11/23 10:11:39 Trace: [remoting/brokerserver] network reachability changed. Kicking off discovery cycle

Every few days, Roon crashes and restarts itself while streaming. Today I caught one of the errors as it happened, and immediately after receiving one of the above notices I saw the Out of Memory error in the logs which caused the crash and reboot.

11/23 10:03:34 Trace: [remoting/brokerserver] network reachability changed. Kicking off discovery cycle
11/23 10:03:35 Info: 
Local Time:            11/23/2022 10:03:35 -08:00
Device Serial Number:  B9192E4D-D0F3-43B1-8299-195A13952ED6
User Id:               be18d754-7d89-476d-b39d-206c7b691367
Roon Version:       2.0 (build 1154) production
OS Version:            Linux 5.15.0-52-generic
Mono Version:          unknown

Application Domain:    RoonAppliance
Assembly Codebase:     file:///opt/RoonServer/Appliance/RoonAppliance.dll
Assembly Full Name:    RoonAppliance, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

   Exception Source:      System.Private.CoreLib
   Exception Type:        System.OutOfMemoryException
   Exception Target Site: Task.HandleException
   Exception Message:     Exception of type 'System.OutOfMemoryException' was thrown.
   Exception Data:        none

   --[ Stack Trace ]------------
   System.Threading.Tasks.Task.HandleException(Exception unhandledException)
       System.Private.CoreLib.dll, N 0
   System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
       System.Private.CoreLib.dll, IL 302, N 66113141
   System.Threading.ThreadPoolWorkQueue.Dispatch()
       System.Private.CoreLib.dll, IL 310, N 66114710
   System.Threading.PortableThreadPool/WorkerThread.WorkerThreadStart()
       System.Private.CoreLib.dll, IL 382, N 66258964

Nothing on the networking ever changes, within the house on the local LAN or (as far as I know) with my upstream ISP. Is there something that I can do to fix the above rediscovery issue, and whether it’s related or not the OoM issue which causes a hard crash?

Hello @rcrawley ,

Apologies for the delay in response here. Are you still seeing this issue at the present time? Do you have IPv6 enabled by any chance? There was a similar report here that was on Linux and due to the IPv6 implementation, please see the thread here:

@noris I do not have ipv6 enabled:

$ ifconfig
enx00e04c0425b4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.15  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 00:e0:4c:04:25:b4  txqueuelen 1000  (Ethernet)
        RX packets 1119977575  bytes 212772611358 (212.7 GB)
        RX errors 0  dropped 13986  overruns 0  frame 0
        TX packets 1028007200  bytes 361739325929 (361.7 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 75177056  bytes 18773671557 (18.7 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 75177056  bytes 18773671557 (18.7 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

$ cat /sys/module/ipv6/parameters/disable
1

Hi @rcrawley ,

Happy New Year! I wanted to check in with you, are you still seeing these issues? Have you tried another Linux machine on this network as a Roon Core? Does it have the same issues if so?

Hi @noris. I am still seeing the issue, repeating in the logs about every 30 seconds. I don’t have another Linux box on the same network where I can try to run a full Roon core, but I do have many RaspPi boxes running a mix of Buster and Bullseye and none of them are showing any indication of flapping or any networking issues. I’m also not seeing any network issues in general that I can tell on the Linux Roon Core box; streams from the local library are never interrupted when streaming to the RaspPi endpoints.

Hope that helps. Thanks!

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.

Roon Core Machine

MacBook Pro
Linux Mint 21.1
3.5 GHz dual-core i7
16GB Memory
Core 2.0 (1244)

Networking Gear & Setup Details

Core and clients connective via ethernet

Connected Audio Devices

Many different endpoints connected via ethernet

Number of Tracks in Library

~60k

Description of Issue

Re-opening this ticket because it was never resolved (@noris): Network Reachability Changed, Immediate Out of Memory Crash

I’m not seeing the OOM crashes on my new core but I am still constantly seeing these messages in my logs, every minute:

$ tail -f RoonServer_log.txt | grep -i reachability
04/13 10:45:05 Trace: [broker/accounts] network reachability changed. refreshing
04/13 10:45:05 Debug: [tidal] network reachability changed. refreshing token
04/13 10:45:05 Trace: [mobile] [remoteconnectivity] Port Verification started due to: network reachability changed, port verification not in progress, starting a new attempt
04/13 10:45:05 Trace: [roonapi] network reachability changed. Kicking off discovery cycle
04/13 10:45:07 Trace: [remoting/brokerserver] network reachability changed. Kicking off discovery cycle

04/13 10:46:32 Trace: [broker/accounts] network reachability changed. refreshing
04/13 10:46:32 Debug: [tidal] network reachability changed. refreshing token
04/13 10:46:32 Trace: [mobile] [remoteconnectivity] Port Verification started due to: network reachability changed, port verification not in progress, starting a new attempt
04/13 10:46:32 Trace: [roonapi] network reachability changed. Kicking off discovery cycle
04/13 10:46:34 Trace: [remoting/brokerserver] network reachability changed. Kicking off discovery cycle

As documented in the previous ticket, nothing is changing on my network. Everything re: Roon is hardwired via Ethernet and all devices have static DHCP reservations, so nothing is changing.

Any idea what’s going on here? I’m not convinced that this issue isn’t related to many other issues I’m seeing with failing to connect to endpoints when changing formats (RaspberryPi RoonBridge RAAT Endpoint Stops After Every Track, "StoppedLostEndpoint") or maybe even the issues I’m seeing with truncated playlists (RoonCore on Fresh MacOS (Monterey) Wipes Out Playlists, Again - #3 by rcrawley).

Hi @rcrawley,

Thank you for bringing these recent issues to the attention of the team. The support team is reviewing each of the threads you’ve created after pulling dedicated diagnostics from your Core and Remote devices. We’ll provide follow-up steps in each dedicated thread and merge threads if we discover any common or underlying issues.

Please stand by and thank you for your patience.

2 Likes

Hi @rcrawley ,

Thank you for your patience here while we’ve looked into this further. We looked over your new log set and we are still seeing some Network Reachability issues.

These Network Reachability traces happen each time that a network interface goes up or down on your Core, this is not necessarily referring to the same network interface that Roon could be actively using.

Can you please share the full network setup details including model/manufacturer of any router, switches, range extenders, etc? Do you have any VPNs active? VPNs may also cause similar network reachability issues.

We did not notice any Out of Memory issues in your latest logs, have you been seeing any further crashes or are the crashes resolved?

Hey @noris. Here are my network details:

  • Xfinity cable internet coming into an Arris Surfboard
  • Surboard connected a Google Nest Wifi access point via Ethernet
  • Google Nest downstream ethernet connected to a TP-Link 16-port unmanaged ethernet switch (TL-SG1016). Everything wired and wireless is on a flat 192.168.1.0/24 network.
  • Roon Core (Linux on a MBP, see below for details) connected to the TP-Link ethernet via a USB-C → Ethernet docking station (r8152 linux driver for a Tobenone docking station, have also tested it with the same driver and a dedicated Anker dongle over the past few months)
  • Endpoints connected via a mix of ethernet via the TP-Link and wireless via Google Nest AP

Roon Core specs:
LinuxMint
Linux roonmint 5.15.0-69-generic #76-Ubuntu SMP Fri Mar 17 17:19:29 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
3.5 GHz Dual-Core i7
16 GB RAM

Core: Roon 2.0 (1259)

The only network device on the Core is the one ethernet device, no wifi, no VPN, nothing else running, and IPv6 has been disabled on the Core as well. Still seeing the reachability logs every 20 seconds.

enx00e04c68041d: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.15  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 00:e0:4c:68:04:1d  txqueuelen 1000  (Ethernet)
        RX packets 17560  bytes 5703181 (5.7 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 13879  bytes 4894845 (4.8 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1708  bytes 444781 (444.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1708  bytes 444781 (444.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I haven’t seen any OOM errors on this fresh install of a Core on LinuxMint (about 1-2 weeks old), so no issues there ATM.

Let me know if you need anything else. Thanks!

Hi @rcrawley,

Thank you for the update!

Please verify that multicast is enabled on the routers you’ve mentioned below and see if that improves anything. It’s possible your routers are blocking traffic from Roon and your logs indicate multicast failures.

If you have multiple non-Roon devices connected to either the TP-Link or Mesh network via WiFi, then I recommend setting up QoS on the TP-Link to prioritize the Roon Core. You will need to select the Core by IP address from a list of devices in a new QoS rule. Here is a guide from TP-Link, although your router’s interface may be different.

We’ll stand by for your response. Thank you!

@connor

Thanks for the suggestions.

Neither networking component in my network support multicast so nothing to enable there, and the TP-Link is an unmanaged switch so no QoS support (that I know of).

But I did disable multicast on the MBP’s network interface where RoonCore is running but I’m still seeing the same log entries:

04/28 14:01:33 Trace: [broker/accounts] network reachability changed. refreshing
04/28 14:01:33 Debug: [tidal] network reachability changed. refreshing token
04/28 14:01:33 Trace: [mobile] [remoteconnectivity] Port Verification started due to: network reachability changed, port verification not in progress, starting a new attempt
04/28 14:01:33 Trace: [roonapi] network reachability changed. Kicking off discovery cycle
04/28 14:01:35 Trace: [remoting/brokerserver] network reachability changed. Kicking off discovery cycle

Linux interface:

enx00e04c0425b4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.15  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 00:e0:4c:04:25:b4  txqueuelen 1000  (Ethernet)
        RX packets 4221894  bytes 1627023600 (1.6 GB)
        RX errors 0  dropped 101  overruns 0  frame 0
        TX packets 8124104  bytes 9250025137 (9.2 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Just a quick update @connor , After disabling multicast on the rooncore linux box, I’m receiving the following log entries which repeat every minute:

04/30 15:08:03 Warn: [multicastreceiver] couldn't bind to iface 127.0.0.1:5350, message: Invalid argument
04/30 15:08:03 Warn: [multicastreceiver] couldn't bind to iface 192.168.1.15:5350, message: Invalid argument

Hi @rcrawley ,

I had a chance to speak to the dev team regarding your case and I have a couple of updates to share.

The reason why you haven’t seen OOMs is because we added a limit the number of Network Reachability traces you can get in a row, so that these traces won’t overrun your Roon core and cause the memory issues.

We have not been able to pinpoint why you are seeing these traces so often. The issue has to be either with the network setup or the Core and we would need to narrow this down.

Do you have any other PCs at all, even if non-linux that you can try to host with and see if the traces still appear? Or if you have Mac duel-boot, testing on the non-Ubuntu environment would be helpful.

Awesome! Thanks for that fix. :grinning:

I have another Mac I can run as a Core overnight and grab logs the next morning to see what it says. I’ll queue that up tonight and test with both multicast enabled and disabled and report back over the weekend.

I misspoke, however, on not having another Linux box to test. I always keep a fresh Core with a full DB available on my Synology 218+ NAS (never running at the same time) as a good failsafe when needed. I ran this Core a few times over the past month, just checked the logs and found the following:

  1. The NAS Core also reports the multicast binding errors but much less frequently, only one entry per log file. When this Core is online it’s’ usually online for a few hours.
RoonServer_log.02.txt:04/29 10:19:02 Warn: [multicastreceiver] couldn't bind to iface 127.0.0.1:5350, message: Invalid argument
RoonServer_log.02.txt:04/29 10:19:02 Warn: [multicastreceiver] couldn't bind to iface 192.168.1.20:5350, message: Invalid argument
RoonServer_log.03.txt:04/24 09:50:37 Warn: [multicastreceiver] couldn't bind to iface 127.0.0.1:5350, message: Invalid argument
RoonServer_log.03.txt:04/24 09:50:37 Warn: [multicastreceiver] couldn't bind to iface 192.168.1.20:5350, message: Invalid argument
RoonServer_log.05.txt:04/22 22:18:23 Warn: [multicastreceiver] couldn't bind to iface 127.0.0.1:5350, message: Invalid argument
RoonServer_log.05.txt:04/22 22:18:23 Warn: [multicastreceiver] couldn't bind to iface 192.168.1.20:5350, message: Invalid argument
RoonServer_log.10.txt:04/20 12:39:37 Warn: [multicastreceiver] couldn't bind to iface 127.0.0.1:5350, message: Invalid argument
RoonServer_log.10.txt:04/20 12:39:37 Warn: [multicastreceiver] couldn't bind to iface 192.168.1.20:5350, message: Invalid argument
  1. I am not seeing any log messages at all about reachability on the NAS, and the NAS Core is on the same network as the Linux Core, both hardwired ethernet, both into the same TP-Link switch, etc.

Thanks again for looking into this @noris. I’ll update my Mac Core findings over the weekend.

@noris No reachability errors from the iMac running a temporary Core this weekend but I did see a few multicast log entries:

05/05 16:30:29 Warn: [multicastreceiver] couldn't bind to iface 127.0.0.1:5350, message: Invalid argument
05/05 16:30:29 Warn: [multicastreceiver] couldn't bind to iface 192.168.1.228:5350, message: Invalid argument

There’s no easy way to disable multicast on modern MacOs’ apparently, so I wasn’t able to test that option. Here’s my interface info, if it helps:

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=50b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV,CHANNEL_IO>
	ether 0c:4d:e9:b3:60:03 
	inet6 fe80::c3:de26:2fc5:f35d%en0 prefixlen 64 secured scopeid 0x4 
	inet6 fdb4:4fd8:3900:0:180c:bb16:6480:31aa prefixlen 64 autoconf secured 
	inet6 fdb4:4fd8:3900:0:3415:d427:e02e:2c2b prefixlen 64 deprecated autoconf temporary 
	inet6 fdef:684e:45af:1999:142f:2755:54e:1493 prefixlen 64 deprecated autoconf secured 
	inet 192.168.1.228 netmask 0xffffff00 broadcast 192.168.1.255
	inet6 fdb4:4fd8:3900:0:d045:8314:ba0b:4f83 prefixlen 64 autoconf temporary 
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect (1000baseT <full-duplex,flow-control>)
	status: active

Hey @rcrawley ,

It’s interesting that the Mac did not display the same issue.

These errors are not alarming for port 5350. From my understanding, this is a Roon service yet to be implemented on that port, so you can safely ignore these port 5350 errors for now.

Your findings so far suggest that there is something about the way your main Linux box is set up where it keeps getting notifications of the network stack changing.

I can’t say what it is exactly is triggering it yet, but at least you are not crashing anymore after the code changes.

Thanks @noris. I agree, very glad to not be crashing. :slight_smile: But today while running a group of zones I noticed that I’m getting (what I think are) new error messages about re-authenticating when a rediscovery event happens. I’ve received a few of these messages that say it’s re-auth’ing until the 30th but keeps but it still refreshes:

05/29 16:50:37 Trace:  [broker/accounts]   doing auth refresh, next=5/30/2023 12:49:32 AM
05/29 16:51:27 Trace:  [broker/accounts]   doing auth refresh, next=5/30/2023 12:50:39 AM
05/29 16:52:27 Trace:  [broker/accounts]   doing auth refresh, next=5/30/2023 12:51:27 AM

The result seems to be that my playlists are stopping every few songs; a track will change, Roon UI will show the track is starting, then it will immediately stop. I tried to grab a batch of logs that happened immediately after a new song was started them stopped and pasted a redacted version below, hopefully it’s helpful. I notice it happens when changing from a FLAC to a low quality MP3 but I can’t say for certain it’s always only during that type of file change.

05/29 16:32:39 Trace: [Loopback  PCM] [raatclient] SENT [2924]{"request":"teardown"}
05/29 16:32:39 Trace: [Living Roon + Basement Roon + Music-Room-851N + vumeters-lo-1] [zoneplayer/raat] Endpoint Loopback  PCM State Changed: Prepared => Idle
05/29 16:32:39 Debug: [raat/tcpaudiosource] disconnecting
05/29 16:32:39 Trace: [Cambridge Audio 851N @ 192.168.1.216:35399] [raatclient] GOT [499836] {"status":"Teardown"}
05/29 16:32:39 Info: sleep 28ms after flush
05/29 16:32:39 Trace: [Loopback  PCM] [raatclient] GOT [2313] {"status":"Teardown"}
05/29 16:32:39 Trace: [push2] retrying connection in 0ms
05/29 16:32:39 Trace: [broker/accounts] network reachability changed. refreshing
05/29 16:32:39 Trace: [broker/accounts] [heartbeat] now=5/29/2023 11:32:39 PM nextauthrefresh=5/30/2023 12:31:34 AM nextmachineallocate=5/30/2023 1:20:36 AM
05/29 16:32:39 Trace:  [broker/accounts]   doing auth refresh, next=5/30/2023 12:31:34 AM
05/29 16:32:39 Trace: [broker/accounts] refreshing account info for email='red' userid=red
05/29 16:32:39 Trace: [fiveaccountserver] POST https://accounts5.roonlabs.com/accounts/3/login
05/29 16:32:39 Trace: [fiveaccountserver] BODY token=red
05/29 16:32:39 Trace: [push2] exception thrown. restarting connection (The operation was canceled.)
05/29 16:32:39 Warn: [multicastreceiver] couldn't bind to iface 127.0.0.1:5350, message: Invalid argument
05/29 16:32:39 Warn: [multicastreceiver] couldn't bind to iface 192.168.1.15:5350, message: Invalid argument
05/29 16:32:39 Debug: [tidal] network reachability changed. refreshing token
05/29 16:32:39 Trace: [mobile] [remoteconnectivity] Port Verification started due to: network reachability changed, port verification not in progress, starting a new attempt
05/29 16:32:39 Trace: [roonapi] network reachability changed. Kicking off discovery cycle
05/29 16:32:39 Trace: [raat] [sood] Refreshing device list
05/29 16:32:39 Trace: [raatserver] [sood] Refreshing device list
05/29 16:32:39 Debug: [easyhttp] [125465] GET to https://api.roonlabs.net/push-manager/1/connect returned after 370 ms, status code: 200, request body size: 0 B
05/29 16:32:39 Debug: [push2] push connector url received from push manager: ws://push-connector-v2-1.prd-roonlabs-1.prd.roonlabs.net/
05/29 16:32:39 Trace: [push2] connecting to push2 connector at ws://push-connector-v2-1.prd-roonlabs-1.prd.roonlabs.net/
05/29 16:32:39 Debug: [easyhttp] [125467] POST to https://api.roonlabs.net/accounts5/accounts/3/login returned after 390 ms, status code: 200, request body size: 42 B
05/29 16:32:39 Trace: [fiveaccountserver] GOT {"status":"Success","userid":"red","token":"red","expiration":30,"email":"red","groups":[]}
05/29 16:32:39 Debug: [easyhttp] [125470] GET to https://api.roonlabs.net/porttest/1/myip returned after 283 ms, status code: 200, request body size: 0 B
05/29 16:32:39 Trace: [roonapi] [apiclient 192.168.1.26:34302] CONTINUE Changed {"message":"Extension Repository loaded (v1.0.15)","is_error":false}
05/29 16:32:39 Debug: [easyhttp] [125466] POST to https://api.roonlabs.net/discovery/1/query returned after 522 ms, status code: 200, request body size: 74 B
05/29 16:32:39 Debug: [easyhttp] [125469] GET to https://api.roonlabs.net/internetradio/2/api/location?format=msgpack& returned after 455 ms, status code: 200, request body size: 0 B
05/29 16:32:39 Trace: [radio/library] got location US
05/29 16:32:40 Debug: [easyhttp] [125468] GET to https://api.roonlabs.net/oauthcb/2/tidal/refresh?token=red returned after 628 ms, status code: 200, request body size: 0 B
05/29 16:32:40 Info: [broker/locations] updating location Tidal:Name=TIDAL:Id=red
05/29 16:32:40 Trace: [push2] connected to push2 connector at ws://push-connector-v2-1.prd-roonlabs-1.prd.roonlabs.net/
05/29 16:32:40 Trace: [fiveaccountserver] GET https://accounts5.roonlabs.com/accounts/3/profileslist?token=red
05/29 16:32:40 Trace: [fiveaccountserver] GET https://accounts5.roonlabs.com/accounts/3/userinfo?token=red&machineid=red
05/29 16:32:40 Trace: [broker/accounts] updated token. New expiration is 6/28/2023 4:32:40 PM
05/29 16:32:40 Trace: [broker/accounts] Data updated. AccountStatus=LoggedIn MachineStatus=Licensed UserId=red
05/29 16:32:40 Trace: [bits] myinfo: {"pushid":"broker/red","roon_auth_token"red","os":"Linux 5.15.0-69-generic","platform":"linuxx64","machineversion":200001272,"branch":"production","appmodifier":"","appname":"RoonServer"}
05/29 16:32:40 Info: [mobile] GOT HTTP API /portverify/red
05/29 16:32:40 Trace: [mobile] Got PortVerify Request from_guid=red
05/29 16:32:40 Trace: [mobile]     Returning guid for verification: red
05/29 16:32:40 Debug: [easyhttp] [125474] POST to https://api.roonlabs.net/roonmobile/1/cores/announce returned after 230 ms, status code: 200, request body size: 1 KB
05/29 16:32:40 Debug: [easyhttp] [125473] GET to https://api.tidal.com/v1/sessions/red?countryCode=US returned after 277 ms, status code: 200, request body size: 0 B
05/29 16:32:40 Trace: [tidal/http] GET https://api.tidal.com/v1/sessions/red?countryCode=US => Success
05/29 16:32:40 Trace: [tidal] transition loginstatus from LoginSucceeded to LoginSucceeded
05/29 16:32:40 Debug: [easyhttp] [125476] GET to https://api.roonlabs.net/accounts5/accounts/3/userinfo?token=red&machineid=red returned after 212 ms, status code: 200, request body size: 0 B
05/29 16:32:40 Trace: [fiveaccountserver] GOT {"user":{"tfa":{"enabled":false},"userid":"red","firstname":"red","lastname":"red","email":"red","joinmailinglist":true,"allowpushnotifications":true,"class":"Normal","groups":[],"dncs":[],"trialallowed":false},"status":"Success"}
05/29 16:32:40 Trace: [broker/accounts] Data updated. AccountStatus=LoggedIn MachineStatus=Licensed UserId=red
05/29 16:32:40 Debug: [easyhttp] [125475] GET to https://api.roonlabs.net/accounts5/accounts/3/profileslist?token=red returned after 222 ms, status code: 200, request body size: 0 B
05/29 16:32:40 Trace: [fiveaccountserver] GOT {"status":"Success","profiles":[{"id":"red","name":"red","birthdate":"19740000"}]}
05/29 16:32:40 Trace: [broker/accounts] Data updated. AccountStatus=LoggedIn MachineStatus=Licensed UserId=red
05/29 16:32:40 Debug: [easyhttp] [125472] POST to https://api.roonlabs.net/porttest/1/port/check returned after 625 ms, status code: 200, request body size: 743 B
05/29 16:32:40 Debug: [easyhttp] [125477] POST to https://api.roonlabs.net/bits/1/q/roon.base.,roon.internet_discovery.,roon.debug.,roon.broker.,roon.dsp.,roon.sood.?roon_auth_token=red returned after 392 ms, status code: 200, request body size: 255 B
05/29 16:32:40 Trace: [bits] updated bits, in 400ms
05/29 16:32:40 Debug: [easyhttp] [125478] POST to https://api.roonlabs.net/roonmobile/1/cores/announce returned after 177 ms, status code: 200, request body size: 1 KB
05/29 16:32:40 Info: [mobile] GOT HTTP API /hello
05/29 16:32:40 Trace: [mobile] Got Hello Request body={"coreId":"red"}
05/29 16:32:40 Info: [mobile] GOT HTTP API /hello
05/29 16:32:40 Trace: [mobile] Got Hello Request body={"coreId":"red"}
05/29 16:32:41 Trace: [remoting/brokerserver] network reachability changed. Kicking off discovery cycle
05/29 16:32:44 Debug: [easyhttp] [125479] POST to https://api.roonlabs.net/discovery/1/register returned after 375 ms, status code: 200, request body size: 1 KB
05/29 16:32:44 Trace: [inetdiscovery] registered 1 devices, 5 services

Just pinging this to keep it open (not sure why it wasn’t automatically closed after 45 days, actually)…