The Roon Team is actively investigating reports of ARC connectivity failure and subsequent poor performance in RoonServer and Roon Remote.
Symptoms broadly include hanging, long loading times, or missing content in Roon after using ARC.
We’re making progress in isolating the underlying mechanism for the issue, but don’t have an immediate timeline for resolution. Restarting RoonServer will temporarily resolve the issue in most cases.
Thank you for your patience and please provide any additional reports below, including all relevant setup details, including your RoonServer machine, ARC device, and an approximate timestamp. We understand symptoms are frustrating for those affected, but please remember to post more general feedback in Feedback and limit posts here to the aforementioned technical details and relevant contextual information.
Asus Router connected by cable to NUC, no VPN for Roon ROCK
Number of Tracks in Library
around 9’000 tracks
As described before, the issue happens without a discernible pattern while listening to my music (local and streaming) through ARC and can happen on mobile network remote or at home in local LAN.
Sometimes after the first track, sometimes 60 minutes into the listening session, ARC states “Poor Connection” and cannot connect to my Roon core anymore. At this point all my other Roon endpoints on my Mac, iPhone or streamer device will have lost connection to the core as well and cannot load any content.
The core stays accessible on my network and I can access ROCK through my browser. A restart there temporarily fixes the issues, allows ARC continue streaming and enables my other endpoints to enable a connection again. But like I said, this fix is only temporary and another crash can happen shortly after.
As a side note: none of my other Roon endpoints cause my core to crash. It is only and always playback through ARC that is causing the issue.
Exactly same use case as Galaxyglider here. This has happened on:off since October last year and is just random as to when it occurs. Sometimes I have been using ARC trouble free all day leave my work office on Wi-Fi to cellular working then after the current song finishes it comes up with poor connection and that’s it, get home core is active on network I can log into Rocks WebUI but nothing connects to core, reboot restores it. It hung the other morning after two minutes of playing on cellular than stopped again it had killed the core. This time though it will connect but get the jellyfish. Other times It won’t find the core at all, so this is new but the overall hanging the core is not. It feels like this issue has always been here but is triggered by only certain events, but with later version this seems to be exposing it more and more.
And I don’t use EA at all since the launch of ARC so this has been in production release for a long time.
@connor thank you for creating this thread it is appreciated, although I honestly believe it has taken way too long to happen.
Clearly from all the posts in multiple threads this has impacted way to many of us, and it sounds like quite a few of us have already given up and deleted ARC from our mobile devices after a lack of action from Roon
I will happily reinstall ARC and do more testing when I see updates that fix these issues.
My issues sound almost exactly the same as @GalaxyGlider and I had 6 crashes on the first 3 days of my holiday until reluctantly moving to PlexAmp (which I have to say has worked like a charm without a blip in the same environment)
On this current use of Arc, since this morning, I have had no issues…
I think the weaknesses of Arc are too many and a full R&D is needed.
If Plex can provide software with one mobile app to do both for that we need Roon Remote and Roon Arc to do the same then that should be surely explored.
I’ll report back if I have issues, with timestamps
Same as Galaxy Glider. I’ve had this problem for several months across different builds of both the core and Arc since at least mid-July and it’s varied. Sometimes I can go only 1 track, other times a few hundred before it happens. I’ve posted logs etc in the other thread but not sure I’ve done my set up:
Roon Core Machine
Roon Server for Linux, Ubuntu Server LTS 22.04, Intel Core i5, 16GB DDR3-RAM
Roon Server Software: 2.0 build 1311
Networking Gear & Setup Details
TP Link Router connected by Ethernet
Number of Tracks in Library
Approx 44k.
As Arc seem to be involved I wonder if posting those details makes sense as well in case there is something in common there.
I’m on a Pixel 7, Android 14 (but also had the issue on 13), ARC is 1.0.44 Build 100220.
I get authentication errors using RoonARC starting 1 h ago. Tried to erase RoonARC data, but without success. Now I can’t even log in to Roon from RoonARC.
There must be something wrong at Roon at the moment. I restarted my Rooncore and it says that there is no metadata connection. It wants me to check my internet connection. It works well though.
@support - this is an honest question. My ARC worked a moment ago, now it is “Unathorized”. This is not cool! If Roon software architecture relies on constant connection to Roon servers, then Roon better provide it to paying cutomers.
Or rethink the strategy of “always online” since this is not cool. Why can’t you guys have a tollerance of some elapsed time to “phone home”?
Yes, same for me, it is working fine now. Yet another proof that it needs constatnly up, high availability servers from Roon, where there is no down time. Else - all clients are down!
I agree, not a big deal for 15 minute outage. But it can be handled better, like ARC can continue to work with downloaded files. Afterall, showing “Unathorized” and “Poor connection” implies that the fault is with me, the user, don’t you agree?
The error handling could be more descriptive but it does rely on a cloud backend likely for some caching /CDN type stuff as well as metadata. Arc is very much a 1.0 product. Hopefully version 2.0 adds more polish.
Exactly. Error could be “Could not connect to Roon Cloud”. And only show it when a cloud operation is performed, like global search. If ARC can connect to the Roon Core, there should not be any errors, else people jump up and down, and start reseting ARC and restarting the Roon core, as the message implies the error is in the user end.
There is no excuse why this can’t be implemented. I did not suddenly become an “Unathorized” user because Roon cloud is down. Also the connection to my Roon core is not poor. Both messages are misleading, and throwing the ball to the user… this should have been in the architecural desing of ARC.
Also, I when I got the “Unathorized” and “Poor Connection”, I could not even go to settings and select offline mode.
All wired to tp-link Deco X60 router through a tp-link non-managed gigabit switch
Connected Audio Devices
multiple endpoints, mostly chromecast audio and some dietPi units with usb DACs (Meridian Explorer 2 and Khadas Tone Pro 2)
Through Arc it I use an iPhone 13 Pro with airpods pro and connect it to a chord hugo.
Number of Tracks in Library
around 100k tracks
Description of Issue
These last days I started using ARC more as I have been working from my office. ARC always worked for me, auto setup and UPNP never got me any problem.
However during the day the connection through ARC will drop while I’m listening to music. Then if I access any roon remote inside the network where the core is located it also loses the ability to show the library or play any music - it keeps “loading”. If I restart the server then everything works again (until it doesn’t)
Already got the logs and did not see anything out of the ordinary. Any help in understanding this will be really appreciated.
Seeing this thread open I started testing Arc again (have given up trying to use it on the last two months).
It took a day and a half with on and off listening to have the error happen again 15 minutes ago (4h30 pm local time). Roon core is unresponsive through remotes on my local network.
Last use of Arc was through Carplay, on 5G connection, song played was St. Augustine by Band of Horses around 2:50 pm local time.
First off, there was a brief outage affecting Roon’s account servers this morning, causing the issues reported by @jazMirti, @Vladislav_Dobrev, @mackid1993 . This is a separate incident from the underlying mechanism under investigation here, and the issue has been resolved by our DevOps and site stability teams. If you encounter any login issues after this point with Roon or ARC, please report them in a new support thread and the QA and support teams will investigate separately.
Given that the titular issue of this thread has affected some of the users in this thread for some time, and we’re deeply familiar with one another’s profile icons at this point, we’re grateful you’ve taken the time to share your technical setup in such detail once again. @Michael_Harris and @Marcelo_Bulgueroni, I’m sure you both feel quite abandoned at the moment.
The reality of this particular issue is that, while broadly reported among this group, it’s so far evaded our efforts to reproduce reliably via the same mechanism. Thus, our ongoing efforts to identify the variables in user setups and identify single events in logs. For those who experience the symptoms regularly, I absolutely empathize with the perception that these efforts are an endless treadmill or smokescreen, given that you’ve yet to see a release containing a fix.
That said, behind the scenes, your reports don’t remain anecdotal evidence but accumulate to provide a clearer picture of how Roon’s connectivity protocols to ARC might trigger negative conditions within RoonServer. We’ve identified at least one mechanism that can cause the behavior you’re experiencing, but we need to be exhaustive with this investigation before we can publicly release any fix or share a timeline.
My broader point is simply to extend thanks to those who feel frustrated by the timeframe of this investigation but have continued to provide technical details. We will certainly strive to make these efforts more transparent to users before perception reaches a negative pitch for those affected.
We’ll post more as soon as we have more details to share from development and QA. Thank you!
