Android ARC app only works for a few days, then subsequent launches it hangs indefinitely on the ARC logo when launching. Only way to get it working again is to delete all ARC app storage (just clearing cache storage doesn't work), doing a force stop, then launching and signing back in again. This then requires reconfiguring settings that get lost because of clearing all data. ARC will then work over multiple sessions for a couple days and then get into the hang-on-launch situation again.
I am running Android 14 on a Google Pixel 4a 5G. I am up to date on Android patches/app store version of ARC/etc. I am not using the Early Access release train of Roon.
Thank you for the report. We’ll investigate this with development.
If you’re willing to provide more granular ADB logs to development, it will greatly expedite our efforts to pinpoint what’s failing. At your convenience, here are instructions you can follow:
Connect your PC to Android phone and install ADB (instructions are here (all platforms)). Then:
In the meantime, you can possibly improve this behavior by shedding the Play Store shell. Please try the APK version of the public release of ARC in the meantime and let us know if it improves this behavior. Note you will need to redownload a new APK for each release on the APK track since Play Store manages automatic updating.
We’ll post an update here as soon as we’ve looked closer.
Your RoonServer machine is reporting multiple local IPs to our servers. Do you have multiple network interfaces configured to access ARC outside your LAN?
If you’re using a VPN and port forwarding to access ARC intermittently, ARC will be retaining session IDs from one connection while using the other. This can cause the precise behavior you’re experiencing.
Please provide some illumination on your network setup and topology and we’ll proceed from there. Thanks!
The Roon server is behind multiple firewall tiers. As such, it has no inbound IPv4 reachability. Never has, never will. It is only accessible via IPv6 on the public Internet.
There are three RFC1918 addresses on the server (all reserved, so never change):
169.254.0.2 – iDRAC OOB management interface
192.168.161.60 – Internal WiFi that the mobile CAN connect to when on the internal WiFi
192.168.255.48 – Zerotier interface that the mobile cannot connect to, as it does not run a Zerotier client
There are two IPv6 prefixes on the server (not counting the fe80:: link locals):
2601:: – This is the actual public IPv6 address (and to date has never changed, though theoretically it could) (The server does NOT have IPv6 privacy addressing enabled.)
fdb2:: – This is an internal IPv6 Unique Local prefix that is not publicly routable. If Roon is not filtering out addresses matching fc00::/7, that’s a bug. That prefix will never be routable on the public Internet for ANY network per the IPv6 standards.
I primarily use the mobile when commuting, so it is connecting most of the time via the IPv6 public address. But I have started ARC while on WiFi while leaving and it appears to seamlessly transition to IPv6 once off WiFi.
I would argue that getting “stuck” on an IP it cannot connect to should not cause the app to simply hang indefinitely at the ARC logo screen. It should time out and try others in the list.
In retrospect, saying fc00::7 should always be filtered out is perhaps a bit extreme. It will work when connected to internal networks via WiFi, for example. So long as ARC doesn’t hang on startup if it can’t connect to one of the ips it was using previously, it should be OK to keep it in the list.
We certainly agree with you. There’s a ticket to address this behavior and hanging is never a desired symptom.
Looking through the topology you’ve listed, you’re probably going to see improvement with the next release of the production build. Please let us know if this symptom improves - the release is forthcoming and should be announced soon in Software Release Notes/
I just got the 1.0.49 update, and ARC is still hanging on startup. Is this the version that is supposed to fix this? Or do I have to do a clear all data cycle again and then it should prevent it from hanging in the future?
ARC can’t audition network interfaces on your RoonServer machine. RoonServer pings our servers; if RoonServer receives a positive response through the open port, that’s the path ARC will use.
We implemented a broader and adjacent fix for Pixel phones in ARC, but it’s not likely to be the root cause of your issue.
RoonServer will sometimes pick a non-working network interface when multiple are available. We have a ticket to address this behavior, but it’s not merged yet.
You might have better luck with the APK download as mentioned if you’re willing to side-load. If you’re not willing to try that, then you can disable the iDRAC or Zerotier interfaces when running RoonServer. These are the draconian workarounds available. Otherwise, we’re going to circle back to revisit logs with a tighter zoom to see what’s really going on here and if a more targeted fix is required.
As previously stated, side-loading is not an option on this mobile. Also, disabling the iDRAC and Zerotier interfaces is not practical, as it will break system management/monitoring.
If you’re not willing to side-load or simplify the topology to circumvent the aforementioned issue with multiple network pathways, then I’m afraid there’s no actionable step for technical support here.
Development and product are investigating better handling of ARC connectivity for the small percentage of users who run RoonServer alongside or within a multitier or highly managed network. Until then, we don’t have the bandwidth on the team to support these cases individually in Support, but experienced users will likely chime in in other categories on Community. I’d additionally suggest adding your weight in Feature Suggestions.