Persistent Roon Ready issue: Eversolo DMP-T10 disappears and reappears (ref#3SNQCH)

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

· Hi everyone,

I’m trying to diagnose a persistent Roon Ready issue with a new Eversolo DMP-T10.

My setup:

Roon Server 2.71 build 1683
RoonOS 2.1 build 271 Production
ASUS NUC 13 Pro running ROCK
Eversolo DMP-T10, currently on firmware 1.1.80 beta
T10 connected by Ethernet
T10 → USB → Eversolo DAC-Z10
T10 IP: 192.168.10.236
ROCK IP: 192.168.10.182

Network path is wired throughout. The T10 is connected to a managed Zyxel GS1900-10HP, and the Roon Server is connected via a Xiaomi/OpenWRT router. Both are in the same VLAN/subnet.

The problem

When using the T10 as a Roon Ready endpoint, playback starts normally, but after some time the zone suddenly disappears from Roon.

A few seconds later the T10 reappears automatically as a Roon Ready device, but playback has stopped.

This is not a simple audio dropout: the entire Roon Ready endpoint disappears and is recreated.

It may happen after a minute, after several minutes, or sometimes the system can play for an hour or more without any issue.

The problem occurs with:

native PCM 44.1/48 kHz
Roon Max PCM Power of Two
no DSP
T10 internal upsampling disabled
different Roon Server restarts/reinstalls

So it does not appear to be caused by high sample rates or DSP load.

What makes this strange

The T10 itself is completely stable in other modes.

It can play:

Qobuz Connect
music from its internal SSD
through the same USB output to the same DAC-Z10

for long periods without interruption.

The USB/DAC path therefore appears stable.

Previously, an Eversolo DMP-A6 was used on essentially the same network path and worked normally as a Roon Ready endpoint.

Network diagnostics

During the Roon dropout I ran continuous ping simultaneously to both devices:

T10: 192.168.10.236
ROCK: 192.168.10.182

When the Roon Ready zone disappears, both devices continue responding to ping normally with no packet loss.

I also checked the Zyxel switch.

The T10 is on port 3. The uplink toward the router is on port 7.

For both ports:

FCS errors: 0
CRC errors: 0
alignment errors: 0
symbol errors: 0
drops: 0
discards: 0
collisions: 0

EEE is disabled.

The switch syslog also shows no link-down/link-up event at the time of the Roon dropout.

So the physical Ethernet link remains up while the Roon Ready endpoint itself disappears.

What I have already tried
factory reset of the T10
network reset
multiple T10 restarts
Roon Server restart
RoonOS reinstall
Production and Early Access branches
firmware 1.1.40 and 1.1.80 beta
native PCM
Max PCM Power of Two
DSP completely disabled
fixed DHCP reservation
different playback modes

A RoonOS reinstall sometimes appeared to improve stability temporarily, but the problem returned.

Restarting only the Roon Server also does not reliably solve it.

One particularly interesting observation:

The system can sometimes become completely stable and play for an hour or more, including at 705.6/768 kHz.

But after restarting the T10, the Roon Ready endpoint may begin disappearing again almost immediately, while ping and the Ethernet link remain completely stable.

This makes me suspect a RAAT/Roon Ready session or endpoint initialization issue, rather than bandwidth, physical Ethernet, USB, or DSP.

Logs

In the Roon/RAAT logs around the failure I have seen events consistent with the endpoint connection being torn down and recreated, including messages such as:

Connection reset by peer
Connection refused
endpoint/zone destruction and recreation

while the T10 itself remains reachable on the network.

There have also been unusually long RTT/synchronization warnings in RAAT around some failures.

Questions

Has anyone seen similar behavior where:

a Roon Ready endpoint completely disappears and reappears,
the device itself remains continuously reachable by ping,
the Ethernet link stays up with zero errors,
native playback/Qobuz on the same device remains stable?

Could this indicate the Roon Ready/RAAT service on the endpoint restarting or losing its session, rather than an underlying network problem?

I can provide the relevant RoonServer and RAATServer logs around the exact dropout timestamps if useful.

Thanks.

Tell us about your home network

· ASUS NUC 13 Pro running ROCK is connected by Ethernet to a Xiaomi router running OpenWrt. The Xiaomi router is connected by Ethernet to a Zyxel GS1900-10HP managed switch.

The Eversolo DMP-T10 is connected by wired Ethernet to the Zyxel switch through an in-wall Cat5e shielded cable. The Xiaomi uplink and the T10 port are in the same VLAN (VLAN 20), so the ROCK server and T10 are on the same Layer-2 network/subnet (192.168.10.x).

ROCK IP: 192.168.10.182
T10 IP: 192.168.10.236

During the Roon Ready dropouts, continuous ping to both ROCK and T10 remains stable with no packet loss. Zyxel switch counters on both the T10 port and Xiaomi uplink show 0 CRC/FCS errors, 0 discards, 0 drops and 0 symbol errors. EEE is disabled. The switch log shows no Ethernet link down/up event when the Roon Ready zone disappears.

Qobuz Connect and local playback on the T10 remain stable on the same network. The issue is specific to Roon Ready: the T10 zone disappears completely from Roon for a few seconds and then reappears.

2

Hey @SERGEY_SHKURIN,

Thanks for the very thorough writeup, the diagnostics you ran actually let us rule a lot out quickly.

Your logs point at the T10 rather than the network. When the zone disappears, the T10’s Roon Ready service closes the connection and stops listening entirely, Roon’s reconnect attempts get TCP “connection refused” for a few seconds, and the device then reappears on a different port each time. Across the last two days we count 71 of these, roughly every 6 minutes, with a new port every time. A new port means a new process: the Roon Ready service on the T10 is exiting and respawning.

On the ping question, ICMP is answered by the T10’s kernel, while Roon’s clock sync is answered by its application, so the two can disagree. Yours do, dramatically. The T10’s median sync round-trip is 44 ms with a worst case of 515 ms, and 66% of all samples are flagged long. Your Marantz AV 10, on the same switch at the same time, sits at 1.1 ms. Consecutive T10 samples swing between 0.9 ms and 212 ms, which is a scheduling stall on the device, not a link problem. It’s also just as bad at native 44.1/16 as at 768 kHz, so this isn’t bandwidth or DSP.

One more piece that we think settles it: your T10’s internal SSD is mounted in Roon as a watched SMB share. Every time the Roon Ready zone drops, that share goes offline 11–14 seconds later. A Roon-Ready-specific fault couldn’t take the device’s SMB server down with it, the T10’s media services are cycling as a whole. Worth adding that the same share dropped out 20 times during your DMP-A6 period too; the A6 was never used for playback, so it went unnoticed.

Two things to try:

  • Remove the T10’s SMB share from Roon’s storage locations and host the library on the ROCK or a NAS instead. Roon keeps a directory watcher on it plus hourly rescans, and re-scans all 880 tracks every time the share reappears, which is adding load to the device each time it cycles.
  • Disable the Power-of-Two upsampling for now. It won’t be the cause, but it takes a variable off the table.

We’d also suggest sending this to Eversolo directly: the service restart and the changing port are visible from their side, and their device logs from around a dropout should show what is killing it. :+1:

3

Nope my T10 has been solid without a dropout like you descibe.

5

since their device-side logs should show what is causing the media services to restart.

Best regards,
Sergei

6

Thank you @SERGEY_SHKURIN, we have the fresh logs and have gone through them. There is a lot here, and some of it does not match what you observed.

First, the most important finding. Every reconnection attempt during today’s failures returns Connection refused from the T10, not a timeout. That distinction matters: the device’s network stack is alive and actively rejecting the connection, which means the RAAT service is not listening at that moment. This effectively rules out DHCP, addressing and link-layer causes, a network or lease problem produces timeouts and unreachability, not an active refusal from a healthy IP stack. It also explains the changing port numbers, since each recovery starts a new process.

Second, the failures did continue today. Timeline from the logs, Moscow time on 11 September: the endpoint connected at 20:43:38, dropped at 20:44:22, reconnected on a new port at 20:44:26, dropped again at 20:44:39, and Roon gave up at 20:44:53. It recovered at 20:54:44 on another new port, held for 62 minutes, then dropped at 21:56:38, and Roon gave up at 21:56:52. The T10 did not reappear for the remaining hour and a half the logs cover.

Third, we could not locate the three-hour stable session. The T10 does not appear anywhere in this Roon Server’s logs on 11 September before 20:43:36. Roon Server was running and logging continuously throughout the day, so this is not a gap in the capture. Could you confirm whether that playback was Roon Ready through this server, or possibly through the T10’s own application or another input?

On the specific measurements you asked about: sync behavior has improved, but not in a way that isolates to the addressing change.

Given all of this, the USB cable and DHCP comparison is no longer worth running. Neither would explain a service that has stopped listening.

One item that has not come up so far: the T10’s SMB share is also configured as this Roon Server’s backup destination, and those backups have been failing. The one today succeeded and uploaded 147 files at 21:01, during the playback session. That means the T10 is simultaneously acting as endpoint, watched storage location and backup target while performing power-of-two upsampling. We would suggest moving the backup destination elsewhere, as that is meaningful sustained write load on the same device.

For Eversolo, you now have an exact timestamp to give them: 21:56:38 Moscow time on 11 September. The question to put to them is what caused the RAAT listener to stop accepting connections at that moment, whether the process was killed by a watchdog or the low-memory killer, or exited after an error. Their device logs from that minute should show it directly. :+1: