· Larger smart playlists (800+ tracks) refuse to play via Arc using Android auto. I get the eternal loading graphic. Smaller playlists (100ish tracks) work fine.
Phone: Pixel 9 Pro 2025 Lexus OEM head unit Wireless Android Auto Up to date Roon Server is Nucleus Titan
Tell us about your home network
· Titan connected to an EtherRegen switch, connected to Netgear cable modem.
I think the next step here is to enable some diagnostics on your account so our technical staff can get some more insight into what’s going on here.
However, before I enable this feature, I’d like to ask for your help ensuring we gather the right information.
First, can you please reproduce the issue once more and note the time at which the error occurs. Then respond here with that time, and I’ll make sure we review the diagnostics related to that timestamp.
Thanks for that! We’re seeing a handful of errors around the time you’ve mentioned - do these playlists contain content from streaming services, or only local files?
If possible, can you create similarly sized playlists and test out using a playlist only with local content, and see if you run into the same issue?
Can you play these playlists on Arc outside of AA? If you start playback before connecting to AA, do you still have issues?
Ok, more testing starting at 1:10p my time, in a different car with Android Auto. Seems like the issue is activating larger playlists from AA.
When trying to activate larger playlists from AA, I get the loading spinner. Same whether the playlist contains streaming tracks or all locally stored. Smaller playlists work fine.
Also works fine when I start a larger playlist from the ARC app directly, then activate AA. But once in AA, if I stop that playback to try a different playlist, I can’t get back to the larger playlist from AA.
Thanks so much for the specific timestamp! From Arc logs, we can see clear errors directly related to Android Auto failing to play a playlist from ARC.
It looks like the playlist fails because:
Track metadata fetches are timing out or being aborted
Android Auto’s playlist UI generation depends on those metadata calls
When enough of them fail, Android Auto cannot construct the playlist → playback never starts
All failures seem to be network / connectivity related, upstream of playback.
As a simple next step in troubleshooting, could you simplify the network chain between your server and primary router? Can you temporarily set a direct ethernet connection from your Nucleus directly into a port on your router.
Let us know if that changes any of the issue behavior - thank you!
Can you please reproduce the issue once more and share the name of the large playlist that failed to initiate via Android Auto here?
If you’re in a position to directly wire the Nucleus Titan to the router per the suggestion above, please take that step first. Otherwise, in any case, we’d like to gather a larger sample size of logging around the issue.
At a minimum, our team will require the name of the playlist that most recently exhibited this symptom in Android Auto in order to pinpoint the event in logs.
OK Roon comrades, I’ve done the tests suggested. I gotta say, messing about with your home networking configuration is a frustrating way to spend an afternoon!
At around 5:30p today, I connected the Titan directly to my cable router (so nothing between it and the naked internet).
The behavior was identical as noted above –
in the ARC app itself, I was able to access playlists large and small, no problem.
in Android Auto, however, I was able to access small playlists (I also tried directly accessing an locally stored album, and that worked fine). But initiating larger playlists (1000+ tracks) gave me the loading spinner forever.
the playlists that I used (and this has been true for all of these tests) are “ALAC last 5 years” (locally stored files only), “past 6 months” (mix of local files and streaming), “past 12 months” (same), and “1982” (90 tracks, streaming).
You have our gratitude - I know network settings modifications are an unthrilling and unwelcome test of patience. Fortunately, we have all we need to proceed with development and we should be able to pin down a root cause.
We’re going to sync with development behind the scenes and attempt to reproduce the issue internally. We’ll respond with next steps and any updates as soon as they’re available. Thank you again for your patience.
