ARC: "poor connection" error only affecting certain album under Balanced or Bandwidth Optimized. (ref#YSOPEE) [Ticket In]

Support
1

Hi! What’s not quite right with Roon?

· Can’t reach my Server, remotes or ARC

Can’t connect to my Server, remotes or ARC

· Other ARC issues

Tell us what's going on

· Hi,

I’m having a strange Roon ARC issue that I’ve narrowed down quite a bit.

Setup

Roon Server running on an Intel NUC
Ubuntu Server 24.04.4 LTS
ISP: NURO Japan
Internet connection uses MAP-E, so normal port forwarding is unavailable
Tailscale installed on both the Roon Server and iPhone
ARC tested over 4G with Tailscale enabled
Tailscale itself appears healthy:

UDP: true
IPv4: yes
IPv6: yes
MappingVariesByDestIP: false
Nearest DERP: Tokyo
tailscale ping between the server and iPhone also successfully establishes a direct connection.

In Roon ARC, both Cloud and RoonServer show green / connected.

What works

Over 4G + Tailscale:

Qobuz playback works
Older local FLAC albums work
A recently added local FLAC album works when ARC is set to:
Settings → Playback → Cellular Streaming Quality → Original Format
The same problematic album also works normally:

in Roon Desktop
in the regular Roon mobile app
in Roon ARC over home Wi-Fi without Tailscale
What fails

For this recently added local FLAC album, over 4G + Tailscale:


ARC Cellular Streaming Quality Result
Original Format Works
Balanced “Poor Connection” — does not play
Bandwidth Optimized “Poor Connection” — does not play
The strange part is that the full original FLAC streams successfully over exactly the same 4G + Tailscale connection, while the lower-bandwidth transcoded versions fail with “Poor Connection.”

This makes an actual bandwidth or Tailscale connectivity problem seem unlikely.

Other tests

I also tried:

Temporarily disabling native IPv6 on the Ubuntu server → no change
Using the Roon Server as a Tailscale exit node → no change
Checking album versions in Roon → there are no alternate local/Qobuz versions grouped with the problematic album
Current suspicion

This looks more like an issue in the ARC server-side transcoding path for certain FLAC files than a Tailscale or network problem.

The key behavior is:

Original Format → works
Balanced → fails
Bandwidth Optimized → fails
ARC reports “Poor Connection” even though the original FLAC can stream successfully
Has anyone seen this behavior with ARC, where specific local FLAC files work in Original Format but fail whenever ARC has to transcode them?

Tell us about your home network

· Nuro fiber in Tokyo. Roon Arc connection through tailscale.

2

Note that transcoding of local files happens on the Roon Server - otherwise it wouldn’t save any bandwidth for the ARC app. So I’m wondering if this isn’t a performance issue on the server (that triggers an incorrect message in the app, perhaps because all the apps notices is that data doesn’t arrive in time.)

However, when using streaming tracks, the download happens directly from Qobuz/Tidal, and it simply serves the lower-bandwidth version. I.e., a Roon Server performance issue should not play any role. Do you get the problem with streaming tracks too?

3

It could be a specific issue with those FLAC files that could be causing an issue.

Roon logs would need checking.

4

I have zero other issues with local streaming. It really seems that the “poor connection” happened only to the album I recently added.

5

Hi, and thank you for looking into this.

I uploaded the complete Roon Server log archive to Roon’s Logs Upload Server under the tag arnaud_plds .

As one example, an affected recently added local album is Jon Batiste — BIG MONEY .

Over 4G with Tailscale enabled :

  • Original Format works.
  • Balanced reports “Poor Connection” and does not start.
  • Bandwidth Optimized reports “Poor Connection” and does not start.

Scope of the issue

Outside of recently added local material, I have no other ARC playback problems. On the same iPhone, 4G connection, and Tailscale setup, other local files play normally across formats, including FLAC at 44.1 kHz and higher sample rates, both in Original Format and when ARC transcodes them.

So far, the only pattern I have found is that the failures are limited to recently added albums/tracks. They do not appear to correlate with FLAC itself, sample rate, bit depth, or available bandwidth.

Key reproduction

  • 7 September 2026, 11:16:03 JST
  • 02:16:03 UTC
  • 4G + Tailscale
  • Jon Batiste — BIG MONEY
  • 01 - LEAN ON MY LOVE.flac
  • 02 - BIG MONEY.flac
  • Lower lossy / Bandwidth Optimized-style request

What the Server logs show

The affected FLAC files are successfully transcoded by the Roon Server.

  • Original Format: Roon logs quality=Original => False for transcoding, with no HLS playlist generated.
  • Balanced-style request: Roon creates a 256 kbps Opus HLS stream. For LEAN ON MY LOVE , it generates all 26 segments and completes the encode in about 3.6 seconds for a 251.5-second track.
  • Bandwidth Optimized-style request: Roon creates a 96 kbps Opus HLS stream. For BIG MONEY , it generates all 16 segments and completes the encode in about 1.6 seconds.
  • In the latest reproduction, the Server again completes the lossy transcodes successfully: 26 segments for track 1 in about 2.9 seconds, and 16 segments for track 2 in about 1.7 seconds.

I do not see a FLAC decoding error, ffmpeg/transcoding error, failed Opus segment generation, out-of-memory event, disk-full event, or Roon Server crash associated with these requests.

My current conclusion

The Server successfully completes:

Local FLAC read/decode → Opus transcode → HLS playlist and segments generated

The remaining unknown is what happens after that, when ARC should retrieve and play the HLS/Opus segments.

Original Format is not a fully equivalent test because it does not use the HLS/Opus path. Therefore, Original playback working does not completely exclude an ARC-side or remote-delivery-path issue.

I also see repeated stream is already closed errors while the Server sends ARC home/album page fragments. These are not transcode errors, but please let me know whether they are relevant.

Could someone from Support please inspect ARC-side logs or service telemetry around 2026-09-07 02:16:03 UTC and confirm:

  1. Did ARC request the first generated .opus segment?
  2. Did that request reach the Roon Server, and was a successful response returned?
  3. If ARC received the segment, did it fail to accept or decode it?
  4. Are the repeated stream is already closed mobile/page warnings relevant?
  5. Is there a known ARC issue involving HLS/Opus playback over Tailscale, especially with MAP-E Internet access?

The important point is that the affected tracks are successfully transcoded into complete HLS/Opus output on the Server, but ARC still reports “Poor Connection” before playback starts.

6

Hello @Arnaud_Plds

Thank you for reaching out to Roon support.

It might be helpful to have the media file(s) for testing on our end as well, can please upload them here and let us know?

https://workdrive.zohoexternal.com/collection/nqcgjac23027d90a441bda2c314de49d7958a/external

7

I just uploaded Big Money of Jon Batiste (it is one of the files that failed during my test, recently added). I would be really surprised if it comes from the files. I can play on arc similar file type, which was added a few months ago. The issue (for a few months) has been consistent on the recently added album.

8

Thanks for sending those files over @Arnaud_Plds, our team has been able to reproduce the issue, with both Original Format and CD quality playback functioning normally, yet Balanced and Bandwidth Optimized throw a ‘Poor Connection’ error (all over cellular data.)

We have a ticket in with our development team for further investigation. Once we have new information or any updates to share, we’ll ping you here directly.

Thanks for your ongoing patience in the meantime! :folded_hands:

9

Thank you!

10

No updates yet @Arnaud_Plds, but we’ll be sure to let you know as soon as there is movement here. :+1:

11

Thanks!
I added new albums and same issue on these last added one too. Quite annoying.

13

Hey @Arnaud_Plds,

Thanks for the update and for checking the newly added albums as well. We’re still investigating this, and we’ll get back to you with any questions or updates as soon as we have them.

14

Hey @Arnaud_Plds,

We’ve spoken with the team and found a possible cause for this issue, and the ticket is now underway. Thanks in advance for your patience as we work to address this.

15

That’s great news! Thanks for the heads up.

If I can be of any help, tell me.

17

Hey @Arnaud_Plds

We have added this info to the investigation ticket. The ticket has been submitted for developer review, meaning that this may take some time to be reviewed.

There aren’t any additional details needed at this time, so we will go ahead and close the thread for the time being, and if any other questions arise after the developers have reviewed the case, we will re-open the thread and reach out once more.

Thanks again for your report, and thank you in advance for your patience as the ticket progresses through the development queue for review.