Tidal playback continuously cutting out (ref#RCMV5E)

Support
1

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· Tidal Cutting Out

Tell us about your home network

· Firewalla Gołd SE into TP Link unmanaged switches

2

Hey @Will_Morr,

Welcome back to the forum. Can you provide more details on when the cutting out is happening, specifically whether it is between tracks or in the middle of a track? Please share the exact local time, date, and track when it next occurs. Does it happen with multiple zones or just one in particular? Is the Roon Server connected via Ethernet?

3

Tidal cuts out at random times. It stops in the middle of a track. Of course, I updated to the latest versions, did hard reboots, and everything is fine now. Roon had a tough time finding the audio zones but they are working normally now.

Roon has been losing connection to Meridian 218 zones. I will record the next time it happens.

The intel nuc running Roon Rock is hardwired to the network as are all the zones which include four Meridian 218s, a Meridian ID41 in a 861v8, and an Eversolo A6.

4

After the last update and a couple of hard reboots, Tidal into the 218s appears stable. I will reach out if the problem reoccurs. Thank you

5

The cut out happened again.

The server is connected via ethernet to a switch which is connected to the router. The 218s are connected to the same switch. We were playing the Project Hail Mary soundtrack from Tidal. It cut out after 30-60 seconds of play and the zone disappeared. The zone comes right back. The zone is a pair of 218s. This occurred at 7:55 AM and I tried again at 6:05 PM and it happened again.

6

Hey @Will_Morr,

Thanks for sharing the above timestamps! I was able to review a fresh diagnostic report surrounding the failures you’ve mentioned.

The logs reveal a series of Network Reachability and Output Buffer issues that caused the playback to stall and eventually skip tracks. Around 18:06:21, the log begins reporting that the audio stream from Tidal is not arriving fast enough to keep the playback buffer full.

The system then hit a critical failure while trying to play the track “I’m an Astronaut”:

[Living Room] [zoneplayer] Output State: Stalled
 [zoneplayer/raat] Error during playback: System.Exception: unexpected transport state: Stalled

Just before the stoppage, there are several “Slow Connection” warnings and DNS-related traces:

  • The log shows FTMSI-B (Roon's file transfer system) reporting accessTimeOut:True for several Tidal blocks.
  • The server was attempting to fetch data, but the response times from the Tidal servers were exceeding the allowed threshold.
Based on the above, let’s see if any of the following troubleshooting steps help:
  • Reboot Network Gear: The "Stalled" state and "accessTimeOut" are classic symptoms of a router or network switch that has a full NAT table or a hung process. Power cycle your router and any switches between the Roon Server and your Living Room device.
  • Check DNS Settings: Since the log shows timeouts fetching Tidal blocks, try changing the DNS on your Roon Server (or your router) to a faster provider like Cloudflare (1.1.1.1) or Google (8.8.8.8). This often speeds up the initial "handshake" Roon makes with Tidal's servers.
  • Wired vs. Wireless: If your "Living Room" endpoint is on Wi-Fi, the logs suggest it is losing its connection to the stream. If possible, test with an Ethernet cable to see if the "Stalled" errors disappear.
  • Tidal Streaming Quality: If your internet bandwidth is fluctuating, try lowering the Tidal streaming quality in Roon (Settings > Services > Tidal) from "Max" to "High" temporarily to see if the buffering stops.
Thank you, Will! 🙏
7

Hey @Will_Morr,

Just checking in on this. Were you able to try the router or switch reboot, and did you get a chance to test a DNS change to Cloudflare or Google on the Roon Server or router? If the Living Room endpoint is on Wi-Fi, it would also be helpful to know whether an Ethernet test changed the buffering or stalled playback, and whether lowering Tidal’s streaming quality made any difference. Please send over any updates when you can, thanks.

8

I changed the DNS servers and did hard reboots of the network, ROCK, and the Meridian endpoints. All equipment is hardwired. No wi-fi is used for Roon playback.

The system made a full day without a drop out. The next day, it did drop out but I don’t know at what time. I believe this issue is network related with the Meridian 218s because I have no issue running a Tidal stream to any of the other endpoints and Roon ARC works flawlessly while playing Tidal tracks to my cell phone.

I will report back the date and time of the next dropout we experience.

Thanks for checking back

9

Hey @Will_Morr,

Thanks for the update! Glad to hear things stabilized even for a short while. It does point to the 218s specifically - we’ll be monitoring for a timestamp the next time it occurs. Thank you! :folded_hands:

10

It actually started stopping again. I just occurred between 8:10AM and 8:30AM this morning. I have two 218 zones linked and was playing a Tidal playlist. Please take a look. Thank you.

11

It cut off again between 10:00AM and 10:30AM

12

Hey @Will_Morr,

Thanks for the timestamp! From a fresh diagnostic report, we saw that the two linked Kitchen 218s have been dropping their management and control connections to your ROCK on a nearly exact 2-hour-1-minute cycle throughout the entire log history.

The 2-hour interval is a very strong signal of a TCP keepalive timeout, likely somewhere in your network stack. When a long-lived TCP connection sits idle (no audio data flowing between tracks), the session ages out.

  1. As a next step, check your switch's settings for "TCP timeout," "connection tracking timeout," or "session table timeout." On many consumer/prosumer switches (Ubiquiti, Netgear, TP-Link managed) the default TCP timeout is 3600 seconds (1 hour) or 7200 seconds (2 hours). Try raising it to 86400 (24 hours) or disabling session tracking for the Meridian subnet.
  2. Another step that will likely improve stability - Set static IPs for all Meridian zones. The logs show the 218s reconnect on new ports each time (port numbers increment by 2, which means each reconnect is a brand-new TCP session. Ensure all four 218s have static IPs or permanent DHCP reservations to eliminate any address-change complications during reconnects.
Thank you, Will! 👍
13

Done. It’s been stable for the last two days. Thank you!

16

Hello @Will_Morr ,

This thread has been reopened at your request. Can you please provide more details regarding the current status? If you are able to share the exact local time + date + track when the issue next occurs, please share it here, we will enable diagnostics for your account.

17

Thanks for looking again. The Meridian 218s have been losing their connection to the Roon Server. I don’t think it specific to Tidal because I think it was doing it with the local library files. The Server and the endpoints are all on the same unmanaged switch.

Please look at the logs for May 20 at 11:41 AM. I was playing Concierto de Avanjvez, Miles Davis, Sketches of Spain on the “Office” zone which is not a Meridian zone. It’s a Eversolo DMP-A6.

The 218s (Kitchen, Living Room, Dinning Room) struggled on 5/22 between 2:15 and 3:15 PM on May 22 with tracks by Enya which are local. There were multiple dropouts.

I have resurrected a Meridian MC600 and have been using three zones from that unit. It appears to work better than the 218s but it should not be the case.

18

Hey @Will_Morr,

Thanks for the update and additional information!

Unfortunately, we’re unable to look back that far, but from a fresh Roon Server diagnostic report, we were able to see very frequent packet loss across the log set, all occurring only during playback of the DR + Kit + LR grouped zone. The rate is roughly 1,000–1,100 failures per minute while music is playing, stopping the instant playback stops.

This is the Meridian SpeakerLink bus protocol, the low-level wired connection between Meridian devices. At this rate, the SpeakerLink bus between the MC600 and the 218s looks to be quite degraded.

A few additional next steps to try:

  • Restart the Roon Server. See if playback is smooth after the reboot, and see how long things remain stable before you start to hear dropouts again.
  • Inspect the SpeakerLink wiring between the MC600 and the three 218s.
    • Any SpeakerLink cables that were recently disturbed, bent, or had a connector reseat
    • Whether any cable to one of the three 218s (Kitchen, Living Room, Dining Room) shows physical damage
    • Try swapping SpeakerLink cables one at a time to isolate a faulty cable
  • Try isolating each 218 from the MC600 SpeakerLink bus. If you disconnect one 218's SpeakerLink and the failures drop significantly, that cable or that 218's SpeakerLink port is the likely culprit.

Thank you, Will! :folded_hands:

19

Benjamin,

I haven’t noticed any significant issues with the MC600. It is not connected to the 218s at all although they are on the same network switch. If the MC600 is dropping packets, it is not really affecting the playback.

Are you asking me to look at the cables connecting the MC600 and the 218s to the network or the cables I am using for the Speakerlink connection to the DSP speakers?

20

Hey @Will_Morr,

Thank you for the update and additional information!

This changes the diagnostic theory a bit, so we took another deep dive into a fresh Roon Server diagnostic report bearing this in mind.

We are seeing that the rnet/RnetJsonClient which is Roon’s control channel to the MC600 that sends play, format, and sync commands to the device. Across the entire log set, this connection is dropping with no data received for >10000ms hundreds of times. Critically, every confirmed audio dropout correlates directly with a burst of these drops.

When the rnet connection drops, the MC600 stops receiving audio timing and format commands. Playback stalls even though the Tidal buffer is at 100%, the data is there, but the delivery channel to the device has collapsed.

Some next troubleshooting steps with all of this now in mind:

  1. Can you confirm the MC600 has a static IP or DHCP reservation? If it's getting a dynamic address, any lease renewal will sever the rnet control channel mid-session.
  2. The rnet drops every 10,000 ms exactly when they occur in clusters, that's the client-side timeout, meaning the MC600 is going completely silent on the control channel. This is different from the earlier TCP keepalive issue. The MC600 may have a firmware-level keepalive deficiency or a known issue with its IP stack under extended grouped-zone operation. Check:
    • Whether Meridian has a firmware update for the MC600 (especially anything addressing network stability)
    • Whether the MC600's own network settings have an idle timeout or power-save mode that could be silencing the TCP channel
  3. If you haven’t yet, try the MC600 zones ungrouped. All dropouts in these logs occur while DR, Kit, and LR are linked as a grouped zone. The rnet drops are more severe and frequent during grouped playback than single-zone. As a diagnostic, play to just one MC600 zone (e.g., DR alone) for an extended session and see if the rnet drops still occur at the same rate. This would isolate whether the grouped zone configuration is amplifying the instability.
  4. Replace the network cable to the MC600. At 192.168.137.46, all three ports are on the same physical device. The rnet drops are happening at the Ethernet level, not IP routing, not DNS, not Tidal. A marginal cable or port could cause intermittent link flap that looks like a 10-second silence on the control channel. Try a new cable and/or a different switch port for the MC600.
Thanks, Will! We’ll be monitoring for your reply 🙏