Tidal tracks grayed out on ARC abroad, can't play until retry on home Roon (ref#CTLH0O)[Ticket in]

Support
1

Hi! What’s not quite right with Roon?

· Music won’t play or issues with my library

Music won’t play or issues with my library

· Streaming tracks greyed out or unavailable

Tell us what's going on

· On 8/16/2026, 21:33:31, I tried to use ARC to play something while being abroad and all Tidal tracks were just grayed out. As majority of my music is Tidal streaming, this meant no music. I am able to browse music using ARC, but no stream will start playing. When I came home at 9/9 and started Roon on Windows, there was a message along the lines "There was problem logging to Tidal", with Retry button. I clicked it and all was fine again.

A million dollar question is: how is one supposed to fix this while being thousands miles from home using ARC, without having to fly back home, clicking on Retry and flying back to continue with the trip? Creating a support request for this to find out what did I do incorrectly and what am I supposed to do next time this happens so I can actually enjoy streaming through ARC while traveling. In my humble opinion it is Roon Core that is dealing with authentication, o it should be Roon Core that will re-authenticate the session, not a physical click to Retry in Roon Remote

Tell us about your home network

· T-Mobile Optical 1G, wired, Roon Core on Debian Linux.

2

Hi @Rp1984,

Thanks for the report, and I’m really sorry you were left stranded without any music! We pulled a fresh Roon Server diagnostic report and were able to trace this all the way back. The short version is that you’re right, your credentials never expired, Tidal never logged you out, and Roon Server should have recovered on its own without you touching anything.

Your logs go back to July 28, so the whole sequence is visible.

At 06:48:20 on August 7, your server stopped logging mid-write and the machine restarted abruptly, no shutdown sequence, and the end of the log file is truncated. That’s the signature of an unexpected power loss or hard reset rather than a clean reboot. Worth saying clearly: nothing in Roon caused this. Right up to the final line the process was completely healthy, flat memory, normal thread count, watchdog ticking, no exceptions.

RoonServer came back up 47 seconds later, but it started before the machine had finished bringing up its own bridge interface. At that moment it could see only loopback:

[ipaddresses] FOUND lo 127.0.0.1
[ipaddresses] SKIPPED enp1s0: no ipv4
[ipaddresses] SKIPPED wlp2s0: no ipv4
[ipaddresses] SKIPPED vmbr0: not up

Every outbound request failed as a result, account login, geoip, the device database, push manager, the ARC announcement, and that included the Tidal token refresh:

06:49:37 [tidal] transition loginstatus from StartupWithCredentials to UnknownError

Your network stack came back within minutes, and everything else came back with it. The Tidal module did not. From that moment until you pressed Retry on September 10, there was not one further refresh attempt, 34 days, zero retries, no contact with Tidal at all.

That’s the potential defect here, which we’ll be taking to development: after a transient network failure during startup, the Tidal login state latches into an error state with no path back out except a manual retry or a server restart. Reachability returning doesn’t wake it up.

We’re writing this up for the team with your logs attached. The design point you raised is the right one: a transient network hiccup at boot should never leave you with a permanently signed-out streaming service and no remote way to fix it.

One thing that would prevent the trigger in the meantime: your setup looks virtualized (that vmbr0 bridge), and RoonServer is starting before the network is up. If you add a network-online.target dependency to the RoonServer systemd unit, it should wait for an address before launching. That doesn’t fix the stuck-state issue, it just avoids the condition that sets it off.

We’ll follow up once we hear back from development on this. :+1:

3

Thanks for looking into this, it is very small issue with dire consequences :slight_smile: For the record, due to previous investigations, Roon is running directly on the proxmox host - it is not in container or any kind of VM.

4

Hey @Rp1984

Thanks for performing that test, we have added this info to the investigation ticket. The ticket has been submitted for developer review, meaning that this may take some time to be reviewed.

There aren’t any additional details needed at this time, so we will go ahead and close the thread for the time being, and if any other questions arise after the developers have reviewed the case, we will re-open the thread and reach out once more.

Thanks again for your report, and thank you in advance for your patience as the ticket progresses through the development queue for review.