ARC unable to access local internal storage/USB storage on cellular data (ref#JAGOKO)

Support
22

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!

23

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.

25

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. :+1:

26

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:

  1. Move a couple local files off of the USB drive and into the internal storage folder of the ROCK. Add this internal storage location as a Watched Folder in Roon so that these tracks are still in your library. I recommend restarting RoonServer and then re-syncing ARC on your WiFi network.
  2. Next, disconnect ARC from WiFi and attempt to play the tracks that are in Internal Storage.

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.

27

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.

28

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!

29

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!

30

Hi @connor thanks for the updates. Happy to wait on the next releases to see where it takes us!

31

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!

32

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.

33

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?

34

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.

35

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!