Uploaded Logs08-08-20 pt3
It was working fine for hours and hours. Then all hell broke loose across metadata, Tidal, and Qobuz. Maybe a token timed out? Once it got one error, it would never work again…
If nothing else, Roon needs to improve how the system recovers from one error…or least give us a way to remote restart the core. This is nuts.
All right. After another day of testing I have concluded it is Roon Core’s fault. Why ? It still happens within a few hours, even after I stripped my whole setup down and hardwired Core iMac direct until there is nothing weird/special about my network. Unless you want to blame Cox/Cloudflare/Ubiquity, which seems unlikely.
Once it breaks, it stays broken, unable to load anything from Roon/Tidal/Quboz, often displaying pink login error box. But the moment I restart Core, then it works 100% again (with no need to login) for a few hours. The network can’t be at fault if restarting the Core fixes it.
Of course original error might be caused by an actual network glitch (unlikely but possible), but even so I would expect Roon to recover and retry. It gives up within a second. There is ZERO noticeable issues on any of my other network services. Plain and simple the kids/wife would kill me if Netflix/Amazon/Xbox/iMusic/YouTube had a Roon like user experience. They stream 4k HDR all day long with no issues. Ergo: Roon needs to handle (network) errors better.
A more likely culprit is that a login/session/token that is expired/lost/corrupted somehow. That explain why I can’t load anything once it breaks, but after a Core restart all, is swell for a few hours. This feels similar to others on forum with issues with constant login to Tidal etc.
Of course my Roon Core is remote from listening room, so it’s a royal pain. A quick shell script hack allows me to restart Core remotely from iPad for now. It works but obviously not a LT solution.
Seriously, Support ?! After sending me on a wild goose chase, ripping up my network when that’s clearly not at fault, you don’t even have the decency to respond, not even once, to my last 6 posts over 5 days, all while I’m trying to help you fix your bugs ?!
Just for future reference, this is what a DNS errors looks like in your own logfiles:
Yesterday I broke my DNS on purpose to test. Logs clearly showed DNS issue:
[easyhttp] [1] Get https://devicedb.roonlabs.net/1/devicedb-prod.zip web exception without response: : System.Net.WebException: Error: NameResolutionFailure
Most of the dozens of log files I shared by now shows sockets being disconnected.
08/10 23:53:06 Critical: [easyhttp] [97] Get https://metadata.roonlabs.net/1/tracks/202:0:88395033/lyricsweb exception without response: : System.Net.WebException: Error: SecureChannelFailure (Unable to write data to the transport connection: The socket is not connected. ) —> System.IO.IOException: Unable to write data to the transport connection: The socket is not connected. —> System.Net.Sockets.SocketException: The socket is not connected
Stop blaming DNS! If only you admitted to having an issue, I would patiently continue to try and help you. But in every thread it’s the same lame excuse, you keep blaming customer’s networks, that used to work fine till Build 571 broke streaming.
Apologies for the delay in getting back to you here, it took a bit of time for your case to reach my queue again and I appreciate your patience here until I have had a chance to review the new info.
I’m looking over the logs and I’m seeing that RAATServer is restarting quite a bit when this issue is occurring. I suggest that we try to set up a fresh RAATServer instance to see if this plays a factor in the issue.
You can generate a new RAATServer instance on your device by following these instructions, but please be aware that this will reset your Roon Settings -> Audio Tab to factory settings and I would advise making a backup of any custom DSP settings you have:
Looking up RAMP mode, this appears to be a WiFi Mesh Feature:
Since we know we are looking for networking issues here, can you confirm if the behavior is the same when you connect the Core to the primary router (or first unmanaged switch after the router if no ports are available)?
Hi Noris
Welcome back! Note some of those RaatServer restarts could have been me. I found once the system starts skipping tracks, it will eventually go downhill and ultimately fail with a “album not found” “Tidal/Qobuz login” issue or “Network error” etc. This may take a few hours in total, but it always happens in the end. At that point nothing works, not matter what I try. All albums/songs fail. That is until I restart Roon Core, then everything immediately works great again (hopefully for a few hours). From there my suspicion that it is not a networking issue per se but a network session issue. My network doesn’t change if I restart Roon Core, yet that fixes the issue 100% reliable (for a while).
Since I’m playing direct to Mac speakers as a test, I now have Internet modem->AmpliFi router->iMacPro. Nothing else. No pi-hole, no Wifi, nothing. I even reinstalled Roon completely, I still had the same issue eventually. So I started the bad habit of deleting the cache and restarting Roon Core as soon as I have any issue. I ran killall Roon; Roon from a shell script. I know that’s not helping debugging, but it buys me an hour of two of listening.
Also FYI RAMP is just using wired ethernet between multiple access points. Its no different than having a router and a switch. RAMP is just a way to configure multiple routers to create a single mesh network over a large area using multiple access points with the same WiFi parameters. It is not applicable here since I’m not using anything on WiFi (except the iPad mini running Roon control). But in any case I tried direct connection too (using only one AmpliFi, not two) it made no difference.
Once again, other services run 100%, including Tidal and Qobuz native apps(that I got just for testing), but they fail from within Roon ecosystem.
I have two tests left:
Test 1. Build a ROCK system on the same network.
Test 2. Migrate DB to office and run on a completely different network (but still on macOS Catalina).
Both involve quite a bit of work and I’m crazy busy at work, but I’m willing to do if it help and if you are available to look at logs and learn from it.
Hope this helps!
Hi Noris
I renamed Raatserver as requested. It’s been running 4 hours against what started as 4 endpoints. There’s only 2 left, but it could be that a play list or something ran out with no activity on those 2 (I wasn’t watching all of them). This does seem to be an improvement, so I checked the log files and they look pretty clean relative to last few days. Very few errors/critical msgs. No network burps, no Tidal/Qobuz login issues, no dead sockets.
Still some of these msgs left against Airplay devices (even tho they are disabled): 08/12 18:42:05 Critical: scx: System.FormatException: One of the identified items was in an invalid format.
at Sooloos.Audio.AirPlay.AirPlayDeviceData.get_DisplayName () [0x00023] in <4023b489b35045c1980046199cfef9b4>:0 But those have been then since forever…
So it may well be a Raaterver issue, should know by tomorrow.
FYI I did upload two new log files (Roon-log-081220) but like I said they are pretty clean, lacking any (network) issues, even though I changed nothing but the Raatserver delete, (esp on the network) since the last 5 experiments which failed terribly. Which kinda proves my point 
Fingers crossed this works…I don’t care about being right, I just want to have Roon working again like it used to in 2019 
Cheers
Hi Noris
Systems been running well since the above. So it was either the Raatserver delete or something server side that fixed it. I will be monitoring over the weekend and will update Monday.
Cheers
Nicol
Happy to hear that there’s been an improvement here since refreshing RAATServer!
Do let me know if there were any other issues you ran into.
This looks like you could have an unsupported character in one of your Airplay names, are any of them using special characters?
Hi Norris
System worked well all weekend, even after I reverted to original network topology and enabled pi-hole. So it really seems as if it wasn’t my network. Did you have any updates on your server side? Or was this a RAATServer issue ? Is there any downside to deleting RAATSever as instructed before, if I ever run into issues again ?
As for HomePods, they were both named by HomeKit defaults, thus both named HomePod, and reached by Kitchen or office descriptor. So no special characters. There are some other devices (Yamaha AVR, Naim Muso Gen 2, etc) that are Airplay capable, and thus discovered, but not enabled for Airplay. AFAICT none has special characters. Is there a way from logs I can tell which unit is discovered the weird characters ?
The only recent update we had was for RoonOS devices - Nucleus + ROCK. Since you are using an iMac, you wouldn’t have gotten the update, so it is possible that RAATServer was indeed the issue.
No downside, except having to re-do your DSP settings.
Thanks for confirming this, let me check with the team to see if they can provide some more context for that Airplay trace.
Can you share a screenshot of what your Roon Settings -> Audio tab currently looks like?
Thanks for the screenshot - can you try to enable the Kitchen + Office zone and change the name by using the pencil? I wonder if having the comma is causing Roon to output these errors.
Okay, tried that. I’ll keep an eye on logs and see if that message still shows up.
BTW HomePods haven’t work for a while, I think after a firmware update. They might be Airplay2 units now, not sure. I tried just now and both show playing but nothing happens.
I just started a “clean” Roon session (deleted cache,logs and Raatserver), to show logs of Airplay issue.
The same file that plays fine on Core iMac won’t play on HomePods. The play pointer just sits at 0sec.
I uploaded logfile Roon_log showing airplay fail.txt just now.
HomePods both v13.4.8 (latest).
Interesting, even though I renamed, and shows up as new name in play bar, shows up as old name in signal path.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
