Hi @Sean_O,
Please try the following test.
Set ARC to “Balanced” or “CD Quality” playback in Settings for both WiFI and cellular.
Play a higher sample rate local track stored on USB over WiFi in ARC. Now, turn WiFI off, forcing a cellular connection, and try to play another track stored over USB. Is there any difference between these two?
We want to assess whether transcoding is a factor - the above test will force server-side transcoding to occur.
We’ll watch for your response. Thanks!
Hi @connor , thanks for the follow up. Did as per instructions, set quality to CD Quality and fired up a DSD512 track on wifi with VPN connection running. Track played fine. Then whilst it was running I turned off wifi on my phone and the track continued. Whilst playing I was able to navigate to other tracks and it played them also… for a short time. I could select various tracks on other albums and they seemed to play but about a minute or two it all went back to the spinning wheel (which eventually ended up giving me a poor connection error if left for a time). (connection is fine btw). Going back to the original DSD512 track on cellular did not work either. Hope this helps.
Hey @Sean_O,
Thanks for the additional information - we’ll share it with our Arc dev’s and vet for additional thoughts and troubleshooting steps. 
Hi @Sean_O,
Thank you for your patience and our apologies for the long delay.
One last test should provide us with a definitive next step to identify the issue:
We’re fully isolating the USB connection. We don’t suspect it’s the cause, and we’re targeting connectivity in our investigation, but we need to compare diagnostic logging from the two storage pathways in a clean A/B test.
Thank you again.
Hi @connor added tracks to internal storage. Disabled the external drive monitoring. Symptoms would appear to be the same as using the external usb drive. Even tried the disabling of wifi whilst playing (using tailscale) and it fails also.
Did a clean installation of ARC on phone also.
I will leave this setup current if you need to check logs.
Hi @Sean_O,
Thanks for running that test for us! I’ve added the results to your ticket, and we’ll update you as soon as we have more feedback or next steps. Let us know if anything changes in the meantime!
Hi @Sean_O,
We have several tickets in the pipeline that should have a positive effect here - developers have been factoring connectivity and playback pretty significantly. If you’re eager to test some of the changes, you can switch to the Early Access branch, where the first batch of fixes will be merged into an upcoming release.
Otherwise, you can expect symptoms to begin to improve with the next series of public Roon releases on the production build. We’ll keep this ticket open so we can continue to investigate the issue after updates are available. Thank you again for your patience!
Hi @connor thanks for the updates. Happy to wait on the next releases to see where it takes us!
Hi @Sean_O,
The Early Access release is out today - if you’re eager to test a potential fix, you can follow the steps in the article shared above to migrate both your server and ARC instance to the testing branch.
If you encounter any issues with the fix, we recommend posting in Early Access directly for our QA team to take immediate action. Thanks!
Hi @connor , whilst I haven’t managed the early access program as yet - I have just updated to the latest versions and the issue still exists with no changes.
Not sure if any of the “beta” fixes were in this version or not however.
Hi @Sean_O,
Thanks for the update. When we look at the most recent failures in ARC diagnostics, ARC simply reports that there’s insufficient throughput to download the file in time to feed the buffer.
~960.0kBps is required for the local files to stream in ARC; the phone’s cellular connection can only give ARC around 700-800kBps at times.
This occurs with Qobuz only a few moments after the local tracks fail - the connection to the Qobuz API isn’t sufficient to download the track to the buffering real time.
Tailscale’s NAT-traversal is robust and there’s very little latency introduced even when they forward requests through a DERP (their relay servers). What does the phone indicate as the strength of the cellular connection when these errors occur?
Hi @connor , speed tests on the phone indicate well over 100Mbs down and around the 20Mb up. This pretty much equates to my home internet speed. Way more than needed. I ran all my usual tests for this and there has been no change it seems. I would even hazard a guess that your software is not reading the cellular connection speed correctly as it is ONLY streaming via cellular that fails. Current speed tests as at 9AM on Monday 31MAR Sydney AU Local time - Phone: 312Mbps down & 17Mbps up (Home Internet currently showing speed test of 85Mbps down and 25Mbps up.) Tried streaming over Tailscale a Kimiko Itoh album and it just times out saying poor connection. Well, pretty confident to say here that its not the connection speed.
Hello @Sean_O ,
Thanks for the update. We’ll take another look at the logging with the team and will get back to you once we have reviewed this further, thanks!
Thanks Noris
Hi @Sean_O,
Apologies for the long delay here, and if this has already been glazed over, but have you tested out using a different machine to temporarily run Roon Server?
Are all the local tracks youre having issues with DSD format? Do you have any other local tracks in a lower resolution setting from the last internal storage location youre having issues with that you’d be able to test?
Thank you! 
Hi @benjamin and @noris ran the update today. Still exactly the same issue with the cellular connection not working over both Tailscale and OpenVPN.
I have resorted to using port forward so I can use ARC on the go and this is working for now.
I would still really like to know why this isn’t working however. I do prefer VPN over port forward.
Can you point me to what to look for in the logs? Is there a NAT issue that I need to look at. Why only over cellular is this an issue?
Hey @Sean_O,
Thanks for the update - happy to hear port forwarding is working without issue nonetheless!
Unfortunately, Arc logs are not available via your Roon Server log folder, so we don’t have much we can offer here.
Per my last reply:
Were you able to give this a test?
Also:
It may be good to temporarily test out using your Mac as a Roon Server to see if you have the same issue. 
Hello @benjamin, I tried a different install on a separate mac mini. Was a fresh install an import - did not import backup file. Seems the same issue is occurring - any tracks streamed via only cellular time out.
In terms of DSD, I have no issue playing any DSD file on this server. The DSD in question was only a test per a request to check server side conversion. All the tracks I am accessing via ARC are 44.1 FLAC files.
In terms of ports and protocols (TCP UDP ETC), is there a change when it goes to cellular? Is there an official list of what ROON uses so I can ensure there is no firewall issues? Although that is what TAILSCALE is supposed to circumvent.
Hi @Sean_O,
Thanks for your patience here.
If your only concern is ARC (and not Roon’s local device discovery, which relies on a wide range of dynamic UPD/TCP ports), then the only port in use is the TCP port listed in Settings → ARC.
We can see transcoding in diagnostics (FLAC → OPUS) taking far longer than normal, sometimes up to 2000ms per segment.
In ARC, please test with “Original Format” toggled on while playing local tracks via cellular data.
Please also upload any track that causes this issue when connected via Tailscale/cellular here:
Media Uploader
We’ll respond with further notes from development. Thanks!
Hi @connor , I removed the port forwarding, and went back to using vpn to connect to ARC. You won’t believe this but it is now working as it did way back when?!? I had run the latest update when it was released and possibly something in that changed in that - I do not know. So this is a real headscratcher for sure. I appreciate the time you and others have put in on this.