Difficulty downloading updates for Roon Server and Roon Remote in Kuwait (ref#DQIAYM)

Support
1

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· For a long time now, I keep having tremendous difficulty downloading new updates for Roon Server and Roon Remote -- whereas I never had this problem originally. In fact, I think the issue may have started when I joined the early release program a few years back, but I am no longer a part of it. But this could also be a coincidence.

It usually takes me hours and sometimes days to get an update to download fully and I am exhausted with this situation.

Roon Server (2.70 build 1671) is on a sonicTransport (i7, sonicOS v2.8). I have found that the quickest way of getting the update to download fully is to toggle the setting to allow local USB audio devices. While a hassle, this is less of a problem right now as I at least have a caveman workaround.

My Roon Remote (currently 2.67 build 1661) is on a MacbookPro M5 Max (which is packed to the gills with memory and storage) running macOS Tahoe 26.5.2. Updates either never start to download and eventually timeout or start then get stuck. I have tried restarting Roon, the server, and my Mac. I have also tried various VPNs (different country nodes). There has been no reliable solution.

I am based in Kuwait (which is why I tried the VPNs to try to see if local networks and any content filtering they may apply were playing havoc).

Tell us about your home network

· My ISP has not changed (fiber to the building then VDSL to my apartment).

My local network is all Unifi (all Wifi access points have wired backhauls and mesh is not enabled) without any complicated VLANs or other configs. I have tried toggling the firewall but that has not made a difference.

All Unifi gateways, routers, switches, and access points are on the latest firmwares.

2

Right after I submitted this, I again tried to toggle the Local Playback setting for Roon Server on the sonicTransporter and then triggered the Roon Remote update and this time it actually completed (after longer than should be the case).

I don’t know if Roon Remote downloads directly from Roon’s servers or CDN [which would be logical] or if it gets routed through the local Roon Server [I cannot understand why that would be the case].

Regardless, the software upgrade process for Roon Server and Roon Remote needs to be made much more bulletproof. I realize that whatever is impacting my particular scenario might be an edge case, but still… I expect more.

I had previously reached out to support for the sonicTransport regarding this issue and they determined that everything is normal from their side.

Note that I do not ever have any problems streaming music (apart from the occasional known Qobuz issue) to various zones, even with various features of Muse activated. In other words, once the updates are installed, I all is ok. It is just the downloading process for the updates that pushes my patience to the absolute limits.

I would appreciate that this test investigated rather than immediately closed just because I eventually managed to update my Roon Remote. Thank you.

3

Hi @Adeeb,

Thanks for laying all of that out. The pattern you described, especially the fact that toggling local playback on the Roon Server side can kick the update through, makes this look more like a download path or routing issue than a problem with playback itself.

Roon Remote does not download through your Roon Server, it pulls updates directly from our servers. So if the update is stalling, we want to look at the network path between your Remote and the internet, and at anything on the local network that could be interfering with large downloads or long-lived connections.

A few things would help us narrow this down:

  • How is the MacbookPro connected when the Remote update stalls, wired Ethernet or Wi-Fi?
  • When the download gets stuck, do you see any consistent percentage or error, or does it simply sit there until timing out?
In the meantime, since the issue seems to respond to a change on the sonicTransporter, we would like to see whether the download is being affected by your local network path. If you can, please try one update with the Mac connected directly to the router or gateway, with VPN disabled and any other network filtering turned off, then let us know the exact result.

If you want, we can also take a look at the sonicTransporter side more closely once we have those details. Please bring it online and we’ll enable diagnostic mode to review further. Thank you!

4

Thank you for your response @benjamin.

All my Roon Remotes (MacBook Pro, iPhone, iPad) are all connected over Wifi6 (Unifi with wired/ethernet backhaul). I do not have internet problems with any other product/site/service.

Sometimes it never starts to download (based on the progress bar). Often it gets to around 15-20% and stops there. Rarely, it gets past 50% then freezes.

When I am patient, I eventually get an error message (but perhaps not always, despite my patience). When I run out of patience (when it has been stuck in the exact same progress bar position for 5+ mins, I restart Roon and try again.

As I have already updated, how can I do this? Do I have to wait until the next update?

Much appreciated. The sonicTransporter and Roon Server are on 24x7x365. Please proceed with activating diagnostics.

Thanks again for your efforts!

5

Hi @Adeeb

We noticed the diagnostic logs from the sonicTransporter haven’t come through yet despite the request going out a few days ago, even though it’s on 24x7x365 as you mentioned. That actually lines up with your download issue: it looks less like “Roon’s updates are just slow” and more like sustained transfers to and from Roon’s servers specifically aren’t completing reliably from your network, in both directions, while everything else you use online works fine.

A couple of things worth testing when you get a chance:

Could you please try temporarily disabling UniFi’s IPS/IDS (Deep Packet Inspection / Threat Management, under your gateway’s security settings)? That feature is known to interfere with long-lived connections to specific external services, and it could be silently cutting off both the update download and the diagnostics upload.

Also worth retrying with a VPN active again, but this time with UniFi’s IPS/DPI disabled at the same time, since you likely tested VPN and the DPI setting separately before rather than together. If logs make it through or an update completes cleanly under that combination, that tells us a lot.

6

HI @vadim,

Thank you for the follow up. Please see below.

When I look at the list of threats blocked due to the Intrusion Prevention Policy Type, the only records I see are related to the sonicTransporter (as a destination) and only on the port used for Roon Arc. There have been 207 of them blocked in the past month. As it seems like a security risk vector, I am hesitant to disable it. Thoughts before I do so, even for a brief testing period? Is there anything I should look for in the logs that might give evidence to your suspicion? (I have not seen anything that stands out in the blocked flows/threats report.)

I should have clarified that the VPN I was applying was on the MacBook Pro and not network wide. I have never tried enabling a network-wide VPN and am not sure I have the time to experiment with that in the short term. If you still think this is important, let me know and I will try to find the time over the weekend.

7

Note that I decided to go ahead and add an exception for the IPS/IDS settings for the sonicTransporter. Let me know if you now see the logs.

8

Hi @vadim. Any updates? Can you see the logs now?

10

Hey @Adeeb,

Thanks for the update!

Thanks for going ahead and adding the exception, that was a reasonable call, and I want to put your mind at ease on the security side.

Those 207 blocked entries aren’t targeted attacks on your network. Because Roon Arc requires an inbound port open to the internet so you can reach your library remotely, that port gets constantly probed by automated scanners and bots that sweep every public IP and port on the internet. UniFi’s Threat Management matches those probes against generic signatures and logs them as “threats,” but they’re opportunistic background noise, not someone actually getting in. 207 in a month on an internet-facing port is completely normal, and nothing in what you’ve described points to a real compromise. Adding the exception for the sonicTransporter didn’t meaningfully increase your exposure.

One thing worth flagging: IPS/DPI can also work against you here. It sometimes throws false positives against legitimate traffic on that same port, silently dropping or throttling real connections, which is exactly the kind of interference we’re trying to rule out for your update downloads. So the exception isn’t just safe, it’s genuinely useful for this test.

That said, we’re still not able to obtain a diagnostic report from your server. If you could, please use the directions found here and send over a set of Roon Server logs to our File Uploader? Once logs have been uploaded, please let us know so that we can check the server for your files, thanks!

11

Thank you for your response @benjamin. I have sent the logs using your File Uploader.

12

Hey @Adeeb,

Thanks for sending those logs over, they told us exactly what we needed to know.

The logs point to a clear culprit, and it lines up with what Vadim and I suspected. Your sonicTransporter maintains a constant background connection to our servers that Roon uses for remote control, ARC coordination, and, importantly for us, delivering the diagnostic-mode request. In your logs, that connection is failing and retrying roughly 1,400 times a day, every single day, and never once succeeds. The specific failure is a handshake header being stripped out in transit, which is the signature of a network device inspecting and rewriting traffic as it passes through.

Here’s the telling part: all of your encrypted traffic to us is perfectly healthy, update checks, metadata, streaming, everything completes fast and cleanly. It’s specifically the unencrypted connection that gets broken. That’s a strong fingerprint of Deep Packet Inspection (UniFi’s Threat Management) or upstream filtering interfering with the traffic it can read, while leaving the encrypted traffic alone.

This also explains both of your original symptoms in one shot. The diagnostic request we sent is delivered over that same broken connection, which is why it never reached your server despite it being on 24/7, and why you had to upload the logs by hand. And large, sustained transfers like update downloads are exactly the kind of long-lived connection this interference tends to cut off, which matches the stalls you’ve been seeing.

One clarification on the exception you added earlier: it applies to inbound traffic to the sonicTransporter on the ARC port, but the connections in question are outbound from the server, so that rule doesn’t cover them. That’s why it didn’t change anything.

The cleanest test is this: temporarily disable UniFi’s Threat Management / IPS-IDS entirely (not just the ARC exception), restart Roon Server, and give it a few minutes. If DPI is the cause, that persistent connection will finally establish, our diagnostic request will come through, and, the real goal, your updates should download normally. Let us know the result and we’ll take it from there.

Thanks for your patience working through this with us.

13

Actually the exception I added was bidirectional.

I have just done this.

Thank you for your help.

14

Hey @Adeeb,

Thanks for clarifying, and for going ahead with the full test.

Good catch on the exception being bidirectional, that’s a useful data point on its own. If it truly covered traffic in both directions and the connection still failed anyway, that actually strengthens the DPI theory rather than weakening it. Threat Management doesn’t always fully “get out of the way” for an exempted flow; depending on how the rule is scoped, the engine can still inspect and rewrite packets in transit even when it’s told not to block them. Stripping that handshake header is inspection behavior, not blocking behavior, so an allow/exception rule wouldn’t necessarily stop it. That’s exactly why fully disabling Threat Management is the clean test, it takes the inspection engine out of the path entirely, with no ambiguity about scope.

So here’s what we’re watching for now that it’s off and the server has restarted:

  • On our side, that persistent connection should finally establish and stay up, which means the diagnostic request we sent should come through on its own. We'll be keeping an eye out for it.
  • On your side, the real goal is whether updates download cleanly. I know you can't force an update on demand, but if that background connection stays healthy, that's a strong signal the update path will behave too.
Give it a bit of time to settle and let us know what you see. If the connection comes through and things look healthy, the long-term fix won't be leaving Threat Management off entirely, we'd look at a properly scoped, permanent exclusion for the sonicTransporter's outbound traffic so you keep your protection everywhere else.

Thanks again for your patience working through this with us.

15

Thank you for your response. Please do let me know once you begin to receive the log data successfully.

Thanks again.

16

Hi @Adeeb,

Unfortunately we’re still unable to request auto-diagnostics from your Roon Server.

Perhaps rebooting your system after making the above changes might help. Otherwise, we’ll continue to wait until you’re able to attempt another Roon update across your devices. :+1:

17

Thanks for the update. Note that I had rebooted the entire sonicTransporter right after I had disabled intrusion detection.

The only other Unifi security setting I have enabled is a bidirectional country filter for only one country (not the US). I assume that your systems are global and that should not hinder Roon in any way.

Anyway, I will wait until the next update and see if download reliability improves. Thank you.

18

Hi @Adeeb,

Thanks for the update. Yes, please let us know how the next release goes on your end.

19

I tried updating Roon Server again today for the latest release and it failed again. The first image shows where the download got stuck. Note that it reached this point quickly (as usual) and then it just stops. The second image shows what happens after it gives up eventually.

Roon Server update stuck
Roon Server update stuck1076×194 15.9 KB

Roon Server update gave up
Roon Server update gave up1076×158 18.2 KB

20

Note that I have uploaded the latest Roon Server logs from my sonicTransporter.

21

After trying another of couple of times to update Roon Server from my Roon Remote app on macOS, (several hours later) I tried to initiate the update from the just-updated Roon Remote on iOS and it worked from the first attempt. I have no idea if this was just coincidental or a fluke, but just sharing what happened.