Playback fails with 'too many errors' message after inactivity (ref#LYFX0T)

What best describes your playback issue?

· Music doesn't start when I press "Play"

What type of Zone is affected by this problem?

· *Network Zones* are affected.

Is the affected network Zone connected with Ethernet or WiFi?

· Ethernet

Does the issue affect all file formats?

· The issue affects *multiple/all* file formats.

Does the issue happen with local library music, streaming service music, or both?

· *Only streaming* music is affected.

Please select the streaming service(s) with which you're encountering playback problems.

· TIDAL

Have you tried logging out and back in again to your streaming service in Roon Settings?

· Logging out and back in had no impact, the issue remains

Do you have an approximate timestamp of when the issue last occurred?

· This morning

What are the make and model of the affected audio device(s) and the connection type?

· Melco S100 / N100 / Mutec MC-3 UBS/Border patrol DAC

Describe the issue

I listen to music for a while, go away and come back the next morning and when I click play, a bar graph shows up like an EQ by the song, however there is no output. Then the app keep’s moving through songs until it says too many playback errors.

Describe your network setup

Bell Fibre / POD / Ethernet to Melco S100 / NUC running Linux / Melco N100 / Mutec MC3 / Border Patrol

Hey @Morgan_Vallis, welcome to the community, and thanks for the detailed report.

The pattern you’re describing, where playback sits there with no output and then advances until Roon reports too many playback errors, points to the endpoint or network path getting stuck after a period of inactivity.

To narrow that down, please try these two things next:

  1. When the issue is happening, open the Signal Path for the affected zone and let us know what it shows right before playback fails. If there’s any format conversion or DSP in use, that will be useful to see.
  2. Since your setup has several network devices in the path, please tell us exactly how the NUC running Linux and the Melco units are connected, including whether any switch, bridge, or power-saving feature is involved between Roon Server and the playback endpoint.
We’d also like to enable diagnostics on your account, then have you note the exact local time, date, and the track playing the next time it happens so we can review the failure window.

If you can share a screenshot of the Signal Path and any recent changes to the network or hardware, we can take the next step from there.

Hi @Morgan_Vallis,

Are you playing to the USB DAC when this occurs, or can you reproduce this problem with the PC speakers?

If it’s only the USB DAC and this only happens after the machine wakes from sleep, try verifying that the device doesn’t need to reinitiate the handshake with the operating system. Is the DAC visible outside of Roon in your sound settings? Try either:

  1. refreshing the Audio page in Roon or

  2. power cycling the DAC

Let us know if this helps. Thank you!

Hi everyone,

Please see below photos I took now.

There is a BELL Fibre Wi-Fi modem / router that I have a POD connected to via wi-fi. From the POD I run an ethernet cable to the MELCO S100. The NUC / N100 are connected to the S100. The NUC sends the TIDAL stream to the N100 VIA USB which sends it to the MUTEC via USB and finally the Border Patrol DAC via coaxial. I don’t have any power saving feature that I’m aware of. The NUC doesn’t have any speakers. I just turned the Border Patrol off and back on and the problem did not resolve.

Thank you

Hi @Morgan_Vallis,

Thanks for the additional details - this helps us pinpoint exactly what’s happening.

After reviewing your diagnostics logs, the issue is clear - when your system sits idle for an extended period, the Melco N100 stops responding to Roon’s RAAT commands. When you press Play, Roon sends a setup request to the N100 to prepare for playback. Under normal conditions the N100 responds in under 100ms:

07:48:30  SENT {"request":"teardown"}
07:48:30  SENT {"request":"setup","format":{"sample_rate":44100,"bits_per_sample":16,...}}
07:48:30  GOT  {"status":"Teardown"}
07:48:30  GOT  {"status":"Success","audio_port_tcp":48254}
07:48:30  Endpoint MELCO N100 State Changed: Idle => Prepared => Buffering => Ready => Playing

After a long idle period the N100 receives the same commands but stops responding entirely - Roon waits 15 seconds and gives up:

18:15:17  SENT {"request":"teardown"}
18:15:17  SENT {"request":"setup","format":{"sample_rate":96000,"bits_per_sample":24,...}}
           ... 15 seconds of silence ...
18:15:33  Failed to prepare MELCO N100 in 15000ms. Giving up
18:15:33  Track Stopped Due to Error → skipping to next track
18:15:51  Failed to prepare MELCO N100 in 15000ms. Giving up
18:16:16  Failed to prepare MELCO N100 in 15000ms. Giving up
           ...

This pattern repeated across multiple sessions - June 13, June 17 noon, June 17 evening, and June 18 early morning - each time after a gap of several hours with no playback.

A few important points from the logs:

  • This is not a TIDAL issue - the streams are fetching successfully every time
  • This is not a network issue - the N100 is reachable on the network throughout
  • The N100 is not responding to RAAT setup commands after idle - this is the root cause

Since the N100 is failing to respond to RAAT after a period of inactivity, this is behaviour that needs to be addressed on the Melco side.

We’d recommend contacting Melco support directly and describing the issue - specifically that after a long idle period the N100 stops responding to RAAT setup requests. They should be able to advise on auto-standby settings or a firmware fix.

Let us know if you need anything else from our side.

Thank you !