TIDAL Playlists Displayed Inconsistently in Roon (ref#MG4WJO)

[5ORYN]

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

· Hello Everyone,
I am having a serious issue with my playlists that started about two weeks ago. I am having problems with all my playlists, especially the ones from TIDAL. Inside the official TIDAL application, everything works perfectly normal and my main playlist has a total of 2,994 tracks. However, inside Roon, the numbers are completely unstable and truncated. Roon randomly displays different track counts like 100, 150, 250, 500, 750, or a maximum of 1150 tracks. It never displays the full list. On top of that, inside the Roon ARC app, the playlists are often incomplete. Since everything is normal on the TIDAL side, the issue is on the Roon side. What could be the cause of this happening?
Sorin F

Tell us about your home network

· The Roon Core is running on a dedicated workstation (S7ORM - EliteMini Series: AMD Ryzen 9 6900HX, 32.0 GB DDR5 RAM, 1TB NVMe SSD). The OS is Windows 11 Pro 64-bit (Version 25H2, OS Build 26200.1655).The workstation is directly hardwired via a certified Cat.7 Ethernet cable to the LAN 1 port (operating at 1 Gbps) of the main AVM FRITZ!Box 6591 Cable gateway. The internet subscription is a stable 250 Mbps Download / 50 Mbps Upload profile provided by Vodafone Germany. The local link has zero packet loss or network latency. The source of this bug is strictly a cloud synchronization failure and a broken database handshake between the Roon core architecture and the TIDAL API, as the issue is entirely nonexistent inside the native TIDAL client layout. Please escalate this directly to your database engineering unit.

[connor]

Hi @5ORYN,

Thank you for your post.

For due diligence, please first sign out and back into Tidal in Roon Settings → Services, and then reboot your RoonServer.

After rebooting, please wait a few minutes for the server to perform a background sync with Tidal, and then verify the track count in the Phatom Silver playlist you’ve shared in your screenshot. Let us know the number you see. We’ll activate logs in the meantime to pinpoint if this is a problem with the Tidal API or something within Roon.

We’ll watch for your reply. Thank you!

[5ORYN]

I followed your instructions exactly, and now the playlist is completely blank, displaying 0 tracks.

[5ORYN]

Now the local directory scanning is completely broken as well. The “Folders” section is stuck in an infinite loading loop.
Even the “My Live Radio” configuration has been completely wiped out now.

[connor]

Hi @5ORYN,

Thank you for your patience. We’ve investigated logs from the server in this incomplete indexing state after the reboot.

What we see is a TLS connection reset occurring with all upstream connections. Everything visible in the logs points to these connections being terminated before they reach Roon’s infrastructure. When you reboot Roon, it sends out a large volume of these connection requests to upstream services, and they all failed simultaneously when (at least metadata and artwork) had previously recovered silently.

We need to first perform some due diligence, so we appreciate your patience. This is not a speed or throughput problem, and since it affects multiple independent upstream services, it’s highly unlikely to be an upstream infrastructural issue. Something in the local network is policing Roon’s connection.

Please verify that the Microsoft Defender firewall has RoonServer.exe and all other Roon-related processes safelisted.

In your Fritz!Box settings, do you have DoT (DNS over TLS) enabled in the DNS section?

If you reboot RoonServer once more, does the nature of the problem change?

Do you have a VPN on the Windows machine? What happens if you use it to change the upstream network path?

We’ll watch for your response. Thank you!

[5ORYN]

Hi Connor, Hi Roon Support Team,

Let us look at the objective facts with complete professional realism. To eliminate any automated claims regarding my local network, I have fully documented my configuration details.
Here is the exact timeline and diagnostic logs from my system this afternoon:
At 16:42 PM, following your recommendations, I performed a complete clean log-out, fully closed Roon, and did a full hardware restart of my workstation.
At 17:12 PM, I booted the system fresh, opened Roon, and initiated the TIDAL login sequence.
After 5 to 7 minutes of continuous looping, the interface froze on the “Waiting for TIDAL login” screen.
Update on current status:
I have since clicked “Retry” and finally managed to bypass the login screen. However, the synchronization result remains entirely broken. Inside Roon, both my TIDAL playlists—“Roon” and “Phantom Silver”—continue to display as entirely empty.
To clarify the exact network specifications that you requested:
Firewall Authorization: RoonServer.exe has 100% full incoming and outgoing clearance on both Private and Public network profiles within Windows Defender Firewall.
Fritz!Box DNS Configuration: As proven by my FRITZ!Box 6591 Cable interface, the “DNS over TLS (DoT)” feature is completely unchecked and disabled. My network path is entirely unrestricted.
VPN Settings: There is no active VPN running on this workstation or within the local home network. The only VPN configuration I own is a secure WireGuard profile used strictly for Roon ARC connectivity, mapped directly onto my portable FiiO device for when I am in transit.
Inside the native TIDAL application on this exact same network, both the “Roon” (2,996 tracks) and “Phantom Silver” (8,537 tracks) playlists function flawlessly, displaying all tracks instantly with complete stability. This diagnostic loop definitively proves the bug is an internal cloud metadata synchronization regression within the current Roon infrastructure. I expect your technical team to address this core software issue directly rather than searching for external network factors.

[benjamin]

Hey @5ORYN,

Thanks so much for the thorough reply! And, based on your tests I completely understand where you stand in terms of the source of the issue.

We took another look at a fresh Roon Server diagnostic report, and the details are similar, but do vary a bit and I’d to explain what appears to be occurring:

The diagnostic logs show the failures are transport-layer connection resets, not application or metadata errors. The deepest inner exception is consistently:

• SocketException (10054): Eine vorhandene Verbindung wurde vom Remotehost geschlossen — "An existing connection was forcibly closed by the remote host." 51 occurrences.

These surface as "The SSL connection could not be established" and they land almost exclusively on api.tidal.com. Crucially, the connection is being killed during the TLS handshake / early in the request, before any Roon or TIDAL application logic runs.

There are no Roon-side database, metadata, or sync-logic exceptions driving this.

Over the same period, api.roonlabs.net (Roon’s own metadata/artwork/device cloud) completed ~1,477 requests with HTTP 200 and zero connection resets. If this were a Roon cloud infrastructure regression, roonlabs.net would be failing too. It isn’t. Only TIDAL’s endpoint is being reset.

The firewall screenshots, the disabled DoT, and the no-VPN statement are all reasonable to provide, but none of them rule out the actual mechanism. They confirm RoonServer.exe isn’t blocked outright (consistent with the logs, many TIDAL calls do succeed at 200), but the problem isn’t a hard block; it’s intermittent mid-stream resets on long-lived TLS connections to one host, similar to what @connor has mentioned above.

With this in mind, let’s see if any of the following help:

• Does the FRITZ!Box has any "parental controls," "filter lists," or per-device access profiles applied to the workstation, and do are any AV/security suite beyond Defender (e.g., one doing HTTPS/SSL scanning) installed? TLS inspection is the most common cause of selective resets like this.
• Confirm the WireGuard adapter is fully inactive/uninstalled on the Windows host itself, not just "not used."
• Test from a different network path (e.g., phone hotspot to the workstation), if TIDAL syncs fully there, it localizes the cause to the home path conclusively.
• To clear the cached truncation once connectivity is clean: force a fresh sync (sign out of TIDAL in Settings → Services, then back in) so change-detection re-pulls all pages rather than skipping.

Manually clearing your Tidal cache wouldn’t hurt either:

• Exit out of Roon
• Find and open your Roon database
• Navigate to Roon/Cache
• Move the contents of the /Cache folder elsewhere, like your desktop
• Try restarting Roon and verify if the issue still occurs

Thank you!

[5ORYN]

Hello Benjamin,

Thank you for your reply and for the analysis provided. However, interpreting the logs from the perspective of a local network issue does not accurately reflect my system’s actual configuration.
I would like to clarify the following technical facts regarding my local network:
Security Settings: The workstation runs exclusively the native Windows security solution.
No general VPN service or network-level antivirus system is configured in my FRITZ!Box router.
WireGuard: This protocol is installed and enabled exclusively on my dedicated Fiio digital audio player for its own specific rule, completely independent of the rest of the home devices.
Previous Adjustments: All the network troubleshooting steps and settings mentioned in your guide were already performed by me much further back in the past, yielding no positive results; on the contrary, the system’s performance was negatively affected.
The core evidence of a synchronization and metadata indexing regression on the Roon Labs servers:
Inside the Roon ARC mobile application, the playlists appear fully populated as text items. However, during actual playback, only about a quarter of the tracks can be successfully streamed.
The remaining tracks appear as simple, inactive titles on the screen with no audio stream. This behavior is identical when trying to sync the integrated TIDAL service within Roon, even though the native TIDAL application functions flawlessly on all my devices and streams any playlist instantly.
I expect this premium software to function 100% correctly without requiring complex networking modifications just to stream a standard playlist.
Please reopen this case manually and escalate the diagnostic logs to your core engineering team for a software regression fix.

[benjamin]

Hi @5ORYN,

Thanks for the thorough reply, and apologies for any confusion here - your case was never closed. The latest logs actually explain the truncation directly, so let me share what we found and the one test that would settle this.

Roon pulls TIDAL playlists in pages of 50 tracks. In your logs, the connection failures hit some of these paged requests to (api.tidal.com}, and when a page fails, pagination stalls, which is exactly why the list stops at round numbers like 250, 500, 750, or 1150. Those are page boundaries, not corrupted database values.

On the cloud-regression theory: over the same period, Roon’s own cloud services completed around 27,000 requests with essentially no failures. Every connection failure is isolated to TIDAL’s endpoint, and each one happens during the TLS handshake, before any Roon sync logic runs. A regression in Roon’s sync engine would affect Roon’s own services too, and it doesn’t.

On the ARC tracks that won’t play: the logs show TIDAL itself returning “Asset is not ready for playback” on those tracks. That’s a TIDAL-side response per track, not a Roon indexing failure.

The one test that would settle this: connect the workstation to a different network path (a phone hotspot is ideal) and check whether the full playlist syncs. If it does, we’ve localized the cause. If it doesn’t, that meaningfully changes the picture and I’ll escalate with that result attached.

That single test takes a few minutes and tells us more than anything else we could try. Looking forward to your results.

Thank you

[5ORYN]

Hi Benjamin,

As requested, I have conducted the isolation test using a mobile hotspot connection ( _Orin network, 2.4 GHz band). To ensure a clean testing environment, I logged out of TIDAL, stopped the Roon Server process, restarted the core, and re-authenticated the account.
The behavior remains identical. As shown in the attached screenshots, the ‘Phantom Silver’ playlist appears completely empty within Roon. However, when opening the native TIDAL application on this exact same machine and connection, the playlist loads immediately with all tracks fully populated.
The testing confirms that the local network, router, and machine are functioning correctly. The issue appears to be strictly isolated within the API synchronization layer between Roon and the TIDAL database during playlist queries.
Please pass these verified findings to the engineering team for review.

[vadim]

Hello @5ORYN,

Thank you for the detailed report. We reviewed your logs thoroughly and have a clear picture of what is happening.

Primary issue - TLS connection resets from TIDAL’s RO-region servers

The logs show 83 connection reset events exclusively on api.tidal.com, all occurring during the TLS handshake before any data is exchanged. Roon’s own cloud infrastructure completed every request without a single failure over the same period, which rules out any issue on Roon’s side.

Your two affected playlists fail differently. “Phantom Silver” (8,537 tracks) resets on the very first request and shows 0 tracks. “TIDAL:ROON” (2,996 tracks) successfully loads the first 7 pages then resets at offset=350, leaving 350 tracks stored:

06/16 16:25:59 GET .../tracks?countryCode=RO&offset=300 => 200 OK
06/16 16:25:59 GET .../tracks?countryCode=RO&offset=350 => ConnectionReset

Critically, your hotspot test on June 25 produced identical resets on a completely different network. This eliminates your home ISP, FRITZ!Box, and local LAN as factors. The resets are originating from TIDAL’s Romanian regional endpoint.

Secondary issue - tracks unavailable for playback in the RO region

Separately from the truncation, the logs show TIDAL returning 401/4005 "Asset is not ready for playback" on specific track IDs. This is TIDAL’s own licensing response for the RO region and explains why some tracks appear in your playlist but cannot be played in ARC.

What to do

Since both issues originate on TIDAL’s side, we recommend contacting TIDAL support directly and sharing that your account uses countryCode=RO but you are located in Germany, and that third-party applications are experiencing TLS connection resets and playback authorization failures that do not occur in the native TIDAL app.

Once TIDAL confirms the RO-region behavior has stabilized, please sign out of TIDAL in Roon, clear the Roon cache, and sign back in - this will reset the playlist sync state and allow a full re-fetch of your playlists.

[5ORYN]

Hi Vadim, Hi Benjamin,

To prevent any fragmentation on this thread, I am providing a consolidated, verified technical overview based on my latest isolation tests.
First, please note that the regional ‘countryCode=RO’ assumption is completely inaccurate. My streaming profile, physical address, and banking are established in Germany since 2018 (with a local German bank performing regular monthly currency conversions for this account).
Roon has also operated flawlessly under these exact German parameters for the last three years without any issues.
To ensure completely sterile testing conditions, I fully logged out of TIDAL, terminated the Roon Server process, performed a clean local database cache purge in Windows AppData, and re-authenticated the core on my local network connection.
The resulting behavior clearly pinpoints a structural synchronization and pagination failure within Roon’s query architecture, entirely independent of my local network or router:
The master playlist ‘Phantom Silver’ (which contains exactly 2,996 tracks) is fetched by Roon but completely truncates at exactly 50 items (4 hours).
This indicates a rigid API page limit failure where Roon processes the initial token page but fails to request subsequent cycles due to metadata overhead timeouts.
The secondary master playlist titled ‘Tidal:Roon’ (which contains exactly 8,538 tracks) has completely disappeared from Roon’s sidebar indexing layer entirely after the database refresh.
The fact that your support team previously accepted my inverted numbers without verifying the images proves that the validation is operating on scripted templates rather than audit-logging the actual image evidence provided.
Crucially, the native TIDAL application on this exact same machine, connection, and German ISP path populates both databases instantly with all thousands of tracks intact and playing seamlessly in High-Res format.
Please pass this comprehensive, log-verified data directly to your core engineering team to manually re-index my sync profile on the backend.

[vadim]

Hello @5ORYN,

Thank you for the additional details and for running those isolation tests.

To clarify on the countryCode - this value is returned directly by TIDAL’s API in response to your authentication, it is not something Roon sets or assumes. If your account is registered in Germany, that is what TIDAL should be returning. Either way, it does not change our diagnosis: the TLS connection resets we observed in your logs are on TIDAL’s side, independent of region.

On the pagination failure - Roon displays exactly what TIDAL’s API returns. We do not cache, truncate, or filter playlist content on our end. If TIDAL’s API returns 50 tracks before a connection reset, that is what Roon shows. The native TIDAL app uses a different API path and connection stack, which is why it is unaffected.

We are not able to re-index your sync profile on our backend - TIDAL’s playlist data is fetched live from their API on each sync. The correct path here is to contact TIDAL support directly and share the connection reset behavior you are experiencing with their API when accessed through third-party applications.

[5ORYN]

Hello everyone,

Please note that this case remains completely unresolved. The API integration issue persists exactly as previously documented, and my system remains entirely blocked.
I am currently awaiting a formal resolution from TIDAL’s escalation management regarding the backend token authentication.
A final update will be posted here as soon as their engineering feedback is received and verified.

[vadim]

Hello @5ORYN,

Thank you for the update. Please note that our community system automatically closes threads after 7 days of inactivity, so if the thread closes before you hear back from TIDAL, simply open a new support thread and reference this one - we will be happy to continue from there.

[noris]

Hello @5ORYN,

Checking in to see how things are going. Since we mentioned that this thread can close automatically after 7 days of inactivity, did you get a chance to hear back from TIDAL yet?

Please note, if the thread auto-closes and you need further assistance, please submit a reopen support request via the technical support help form below and specify that the issue should be reopened. Thank you.

Technical Support Request

[5ORYN]

Hello Noris,

Their team is currently working on this matter.
I will get back to you as soon as I have an answer from them.

Please keep this thread open. Thank you.

[noris]

Hello @5ORYN,

Thanks for the update. We’ll be standing by while TIDAL’s team works on this matter, and we’ve extended the auto-close period a bit so you have more time to share the outcome.

Please keep us posted when you hear back. If the thread closes before then, we can continue from a new support thread or a reopen request as needed.

[5ORYN]

Dear Roon Support Team,

Please consider this my official request to close this support topic.
As the core integration failure with TIDAL has remained completely unresolved since the escalation on June 26, I have decided to discontinue my usage of the platform.
Thank you for your time and for the assistance provided throughout this process.
No further technical investigation or troubleshooting is required from your side. You may officially archive and close this file.

Sincerely,
Sorin F