I have made a couple of changes to my setup:
Roon running on Synology DS918+ > Lumin U2 Mini > McIntosh C2700/DA2.
- Removed the #ROONONLY
- Resync delay = 100 ms
- Clock Master Priority = 1 (from default to 1)
And the problem is gone….
I have made a couple of changes to my setup:
Roon running on Synology DS918+ > Lumin U2 Mini > McIntosh C2700/DA2.
And the problem is gone….
My bad.
It didn’t go away after all.
I just had to restart the Roon package on the DS918+
· None of the above quite fits
· None of these quite match
· Roon will not start playback om my miniDSP SHD (MCU version 1.85, DSP version 1.15, Volumio version 3.877) after the SHD i switched on from standby. Album and track shows up in the replay kontrol, but there is no progres from 0:00, and repaly starts skipping tracks. A restart of Roon Server Software (version 2.58 build 1608), enables playback. Roon servers runs on ROCK, OS version 2.1 build 271). ROCK and SHD are wired to the same switch (not managed).
· Router Asus RT-AX57. Switch ZYXEL XMG-108. All devices are wired to the switch. Router only for wifi and WAN. No VPN.
I have connected a stand alone dac (Denafrips Enyo 15) btw the Lumin and the preamp with usb cable.
If I switch off the dac, switch on again - the Roon has lost connection or at least I can’t start playing.
BUT, if I go to Roon setting > Audio > select Lumin - and then change a random setting and save it, then I can start the playing.
BR Jesper
Hello Everyone!
For any users who’ve been added to this thread over the last few days, we’ve merged reports of this problem into a single tracking thread so affected users can receive updates.
Our team is actively resolving this issue as a top priority. Expect real-time updates here as the investigation progresses. ![]()
I think this is related too… (don`t see it here)
https://community.roonlabs.com/t/roon-version-2-58-with-eversolo-a6-g1-problem/314738
Is this also happening in the Early Release that’s in the field now too??
I do have exactly the same issues, reboot rs130 or Roon nuc solved the problem
Also since last update
Hello,
Does today’s 2.60 update address this at all? I didn’t see anything in the release notes.
It doesn’t seems so. Waiting also here (problem doesn’t occur on all endpoints) for a fast hotfix.
In my system the problem persists with ROON server v. 2.60 (build 1629) – after my miniDSP SHD is switched on from standby, playback starts but do not progress from 0:00. Restart of the ROON server enables playback.
Somehow ROON is able to switch source to LAN on the SHD after the SHD is switched on from standby.
No, it doesn’t
Still have to reboot
· None of the above quite fits
· None of these quite match
· After restarting my Roon server on my Mac mini M4, Roon doesn't recognize Roon Ready devices on my network until I restart the wifi router. (i.e. they don't show up under Settings>Audio, and they aren't available to stream to.)
If I restart the Roon server again, or restart the Roon Ready devices, they will show up in the listed devices under Settings>Audio again for a second or two, but then disappear. The only way I have found to connect to them again is to unplug and replug the wifi router.
· All devices are connected via wifi to a Buffalo WSR-3200AX4S
Didn’t fix the problem with connecting to Lumin U2’s ![]()
Still need to disable/enable in audio settings for my DMP A6 to work….
The 2.60 update does not resolve the playback initialization issue for affected setups, and core functionality has now been impacted for days.
The lack of concrete operational guidance increasingly feels like PR-style silence rather than active incident communication.
Could you please confirm whether this is a build-level regression and provide a concrete, supported downgrade path to a known-good build as a temporary workaround?
You wrote:
Users may subscribe to a service, but they are paying for a reliably functioning core service.
When an update breaks core playback functionality for days, this becomes a service reliability and incident-handling problem, not a question of version entitlement.
Without turning this into a legal discussion about SLAs or penalties (which I know are not part of the contract), there is still an ethical dimension here.
When a paid service introduces an update that breaks a core function for multiple days, weeks, users effectively experience service degradation without any meaningful choice or compensation.
In such situations, what is the service’s ethical stance on responsibility toward affected users? Is there any consideration for concrete mitigations (such as providing a supported downgrade path, temporary credits, or other forms of acknowledgment) when core functionality is disrupted by a release?
Even a clear statement on how you think about responsibility and user impact in cases like this would go a long way toward rebuilding trust.
In my setup, the system is arranged so that when I turn off the amplifier, the streamer also turns off automatically. The router and the server, of course, are always running.
When I turn the system back on (amplifier, streamer), Roon first searches for the streamer and only finds it after a prolonged attempt (which is already annoying).
Then comes the real issue: everything appears to be fine, but when I start a track—either from my local library or from TIDAL—everything seems to work, the signal path is shown as connected, yet the player stays at 0:00 and nothing happens. The music does not start playing.
I have now found a workaround that makes playback start without having to completely kill and restart the Roon server:
Roon → Settings → Audio → (Device Setup) → Show Advanced → Max Sample Rate (PCM)
Here I change the max sample rate from its current value to any other value (the point is simply to select a different value), save the setting, and playback starts working.
I hope this can help identify and eliminate the issue caused by the update. I would appreciate a proper response to this post here on the forum.
This setup is very similar to mine and problem description matches 100%.
Roon Server 2.60 running on Ubuntu 24.04 (hw is Intel i3 NUC)
wired ethernet via unmanaged switch
MiniDSP SHD
Active speakers
Every night, MiniDSP and speakers are powered down simultaneously. Roon server always runs. Every day, after they are powered up, first attempt to play something in Roon results in failure with symptoms already described by @Laszlo_H and others. Problem can also be reproduced sometimes, not always, by putting MiniDSP to sleep for a long time and then waking it up.
Until now, I’ve been restarting the server using
sudo systemctl restart roonserver
which would fix the issue, but I can confirm now that the workaround @Laszlo_H identified works for me too.
This problem did not exist before Roon server 2.58.
I would appreciate if you could urgently look into this.
Thanks!
– Stanislav