Thank you for the detailed update and the new timestamps. This information was incredibly helpful.
The comparison you provided is definitive. Since the Hegel H390 worked perfectly on the same network switch immediately after the Lumin failed, we can effectively rule out your Roon Server, router, and general network health as the root cause.
The logs indicate that the issue is specific to the Lumin U2’s power management state. Essentially, the device appears to be entering a “Deep Sleep” mode during inactivity, and its Roon Ready module is failing to wake up the network stack in time to perform the necessary handshake.
To resolve this, we need to adjust specific settings within the Lumin App (not Roon) to prevent the network interface from sleeping. Please apply the following configuration recommended for Roon stability:
Open the Lumin App and go to Settings > [Your Lumin U2] > Options.
Roon Ready: Ensure this is set to On.
Lumin Streaming (AirPlay): Set this to Off temporarily (to reduce network stack complexity).
Auto Power Off (or Sleep): Set this to Never.
This is the most critical setting to ensure the RAAT network service stays active even when idle.
Gigabit Network Standby: If available in your firmware, ensure this is set to On.
You can verify these settings in the official Lumin Online Manual here:
Please test playback after applying these settings (specifically setting "Auto Power Off" to "Never").
If the issue persists despite these changes, please let us know. We will then open an internal ticket with our development team to investigate potential firmware incompatibilities with the latest Roon build and work directly with Lumin engineering on this case.
I did successfully adjust the Resync Delay to 1000ms but I’m afraid the problem remained when I switched the DX-10 to CD play and then went back to music streaming
I have checked the Luxman App setting but cannot find either of the labels you suggest. When I tried to access the web interface (192.168.0.60) the address was ‘not available’.
One thing I noticed on my journey was that on the audio page where the three bridge devices are shown, the other two (Cambridge Audio streamer and Uniti Atom) are both identified correctly, whereas under Device Setup for the Luxman (which appears incorrectly as Luxman NT-10) there is a Bridge Device (Luxman NT-07) and an Audio Device (Luxman Super Audio CD Player D-10X) but that is also labelled an ‘Unidentified device’ and in blue ‘?Identify this device’.
Further down the same page where other network devices are listed the Luxman NT-07 appears with the same network address as the NT-10 above but is greyed out unlike all the other network devices.
Thank you for the pinpoint analysis regarding power management. I have strictly followed your instructions and applied all the recommended settings within the Lumin App:
Roon Ready: Confirmed On
AirPlay: Set to Off (Lumin Airplay was not used before and during my tests)
Idle Sleep: Set to Off (The device remained fully powered on during my tests)
Lumin Firmware updated to latest, no Gigabit Network Standby Option
The issue persists despite these changes. Here are the latest timestamps from my testing on Feb 4th:
21:15 – 21:19 (Local Time): Tried to play music via Roon. The same failure occurred, even though the Lumin U2 was fully awake.
21:20 – 21:21 (Local Time): I immediately switched to the Lumin Native App to play the same track. It played instantly and perfectly, proving the hardware and network connection are active.
21:22 – 21:25 (Local Time): I switched back to Roon to try again. The playback failed again.
At this stage, we have ruled out the Network, the Roon Server (Mac mini), the Router, and now the Lumin Power/Sleep settings. The fact that the Lumin App works while Roon fails at the exact same moment points to a critical failure in the RAAT handshake implementation between the current Roon build and Lumin firmware.
Since the problem still persists, please proceed with opening an internal ticket. I would appreciate it if your team could work directly with Lumin engineering to investigate this potential firmware incompatibility. I am eager to get this resolved so I can fully enjoy my system again.
I´ve tried this but the problem is when rebooting my Mac Mini (Roon Server) the Roon Core app would not start up. The message on the screen says “Waiting for Roon core to start” or “Try another Roon core”.Then I have to quit the Roon app and try starting the Roon app again. When I finally get Roon Core up on my Mac Mini server again, my main Roon endpoint (Auralic Altair G2.2) would not play music, just stepping though some seconds on each music file without any sound. Then I have to restart also the Auralic Altair G2.2 again. This all starting after updating to Roon version 2.58. Never happened before that.
To help narrow down the scope, I want to additionally point out that @Paul_Blaik in this thread is experiencing the exact same issue using a Roon Nucleus with a Lumin U2.
Since my setup uses a Mac mini, this confirms that the timeout failure is not platform-specific.
It affects both macOS and Roon OS (Nucleus).
This further reinforces the evidence that the issue is a regression in the RAAT handshake logic itself, rather than a local OS or network permission setting.
I hope this helps the dev team narrow down the cause within the core software/firmware communication.
Thanks for giving that a try and for the additional information around the device being unidentified. Let’s see if we can fix that.
Go to Settings > Audio.
Find the Luxman zone. Even if it says "Luxman NT-10" or "Unidentified," click the Device Setup (gear icon).
Click Identify this device.
Manually search for and select the Luxman D-10X.
Why this matters: When a device is "Unidentified," Roon uses generic drivers that often fail to re-initialize a USB connection once it’s been interrupted.
You also mentioned the NT-07 appears twice (once correctly, once as an “NT-10” and greyed out).
In Settings > Audio, look at the "Greyed out" devices at the bottom.
If you see any old versions of the Luxman setup, click the gear icon and select disable.
A "ghost" device can cause the server to send packets to the wrong internal ID, which is why a reboot (which clears the cache) temporarily fixes it.
· A connected audio device is not appearing in Roon
What type of Zone is affected by this problem?
· *Network Zones* are affected.
How is the affected Zone connected to your RoonServer machine?
· Network - Ethernet
Which network audio protocol is the Zone using with Roon?
· RoonReady
Does the device show up at all in Roon Settings -> Audio?
· No, it does not show up there
Does the device play audio from another source when using the same connection?
· The device has no problems with another audio source
Have you checked that Roon is whitelisted in any firewalls?
· I've checked the firewall and the issue remains
Since you are using a network connection to the device, please ensure that your RoonServer is on the same subnet as the device
· My devices are on a single subnet but is not visible to Roon
Do you have a complex network setup?
· Both the device and RoonServer are connecting to a *single router*
Try to disable any additional networking interfaces on your RoonServer machine.
· Disabling network interfaces had no change in behavior
Check to make sure RoonReady mode is selected on the device.
· I've checked this and the issue remains
If the device has multiple output options, do the other options work as expected?
· Only one output type is affected while the other output type works as expected
Is the device using the latest firmware as per the manufacturer?
· Firmware is up-to-date but the issue remains
Do you have an approximate timestamp of when the issue last occurred?
· The problem occurs irregularly and apparently with no pattern.
What are the make and model of the affected audio device(s) and the connection type?
· Lumin T3X. Roon Nucleus and Windows (separate cores). Wired, with optical into the T3x.
Describe the issue
My Lumin T3x (and a friend's T3x running on a Nucleus) frequently disappears as a Roon endpoint since the update to Build 1608. The device remains visible and functional in the Lumin App and JPlay, confirming the network is stable. This setup was 100% stable before the latest Roon update. Symptoms: The T3x becomes invisible to Roon, often after a period of inactivity. Toggling "Roon Ready" off/on in the Lumin app or a full power cycle of the T3x temporarily restores the connection, but it eventually drops off again. Troubleshooting performed: • Assigned DHCP reservations (reserved IP) for both Core and Player. • Set "Idle Sleep" to "Never" in the Lumin settings. • Disabled IPv6 on the Windows 11 Core machine. • Set Windows Power Plan to "High Performance" and disabled "Energy Efficient Ethernet". • Cleared the Roon Cache folder. • Rebooted the entire network chain (Router -> Switches -> Core -> Player). System Details: • Core 1: Windows 11 Mini-PC (Ethernet to Asus RT-AX89X). • Core 2: Roon Nucleus (direct connection). • Player: Lumin T3x (Firmware v19). • Network: Wired Ethernet with optical isolation (SFP). Since this occurs across two different households with different Cores (Windows vs Nucleus) but the same Lumin model, it points towards a software regression in Build 1608 related to RAAT or device discovery. Any assistance or an upcoming fix would be greatly appreciated.
Describe your network setup
My core is on an ASUS windows PC. My friend has Nucleus.
Thanks so much for the additional information and I’m sorry to hear you’re still experiencing this behavior.
While our devices team takes a closer look into things, let’s see if refreshing your RAAT Server may help.
You can generate a new RAATServer instance on your device by following these instructions, but please be aware that this will reset your Roon Settings -> Audio Tab to factory settings and I would advise making a backup of any custom DSP settings you have:
Just uploaded my log files with the zip filename as dtdcampbell. In addition to the timestamp of 02/02/2026 9:10am est I also did it again at 02/04/2026 4:08pm est
Let me know if there is anything else I can do to assist with troubleshooting.
After the 2.58 update, I am experiencing literally the same problem. My system is macOS Sonoma 14.8.3; before the update there were no issues. Respectfully but firmly, I ask the developers not to treat this as an isolated issue and not to push users toward various workaround “tricks” (which, by the way, do not work). The problem has clearly appeared since the update here as well, and the source of the issue should not be sought in devices that were previously functioning properly. Atletico is using different devices and a different operating system, yet the problem we are experiencing is literally the same.
Thanks for sending over logs and timestamps! We were able to pinpoint the failure and want to see if refreshing your RAATServer database may help.
You can generate a new RAATServer instance on your device by following these instructions, but please be aware that this will reset your Roon Settings -> Audio Tab to factory settings and I would advise making a backup of any custom DSP settings you have:
Thanks for the suggestion. To save everyone some time: I have already performed a complete clean reinstall of macOS and Roon recently while troubleshooting this.
Since a fresh OS install automatically creates a brand new RAATServer instance, resetting the folder again would be redundant and likely won’t address the root cause, especially since the same issue persists on a Roon Nucleus (as reported by @Paul_Blaik) and occurred immediately after my clean install.
Given that we’ve ruled out the local database and OS environment, I’d prefer to wait for the Devices Team’s findings. Have they been able to identify any specific changes in the RAAT handshake or timing thresholds in the recent builds that could be causing this timeout with Lumin?
Hello Benjamin,
Thanks for getting back to me so swiftly.
I have done as you asked and entered the Device Setup of the Luxman NT-10 (of the three devices listed under ‘Roon Ready’. Under ‘Bridge Device’ it identifies Luxman NT-07. Under ‘Audio Device’ there is a speaker icon and three lines of text which read:
Unidentified device
Luxman Super Audio CD Player D-10X
(A circled question mark) Identify this device (in blue)
When I click on the last of these and scroll down to the Luman icon the only available device is the Luxman NT-07. When I enter ‘Luxman DX-10’ in the search box it responds by saying ‘No devices found that match Luxman DX-10’. I have tried entering the full name of the DX-10 with the same negative result. All three audio device boxes are greyed.
Further down under ‘Other network devices’ the Luxman NT-07 is listed among a total of eight devices and is the only one greyed out. Next to the speaker icon and under the Luxman heading reads ‘via AirPlay2’ in small letters.
The listing of zones in all my Roon locations has now changed. There are now two Luxman icons, one a speaker (labeled NT-07) and one a player (labeled NT-10). Engaging the speaker NT-07 zone, even after changing DX-10 functions, the software will play but only at 44.1Khz via Airlpay2.
Thank you once more for your patience and perseverance,
It appears that these timestamps belong to your friend’s Nucleus, rather than your own machine.
In this case, the best course of action is to ask your friend to open a new support thread from their own account. This ensures we are troubleshooting the correct license and hardware configuration.
Alternatively, if you wish to facilitate this, you can collect the logs directly from their machine and upload them for us to review.
Thank you for uploading the logs.
We can see that FIIO refuses to connect, but we cannot see the logs after rebooting to compare them with a successful connection. Please upload the logs again where you have a successful playback.
· When I stop listening to music end of the day, I switch off my Copland DAC (it has tubes), and my Lumin U2 streamer automatically switches off after half a hour. My i5 NUC with ROCK (most recent version) stays running all the time. Each time since the last update from Roon/Rock (last week), I have to restart my NUC again when I want to listen to music the next time. The ‘cursor’ stays hanging on ZERO when I try to start the music in Roon, and jumps to the next track after a little while and so on (everything further in Roon looks normal at first glance) A good friend of mine, also with a Lumin U2 (but the small Nucleus) has the same issue, but another good friend, who has a different brand of streamer, has no problem. I hope you can help me?
Best regards, Henk-Willem
Tell us about your home network
· Standard router from provider Ziggo with Netgear GS105 switch (Cat 7 cables)
· When I stop listening to music end of the day, I switch off my Copland DAC (it has tubes), and my Lumin U2 streamer automatically switches off after half a hour. My i5 NUC with ROCK (most recent version) stays running all the time. Each time since the last update from Roon/Rock (last week), I have to restart my NUC again when I want to listen to music the next time. The ‘cursor’ stays hanging on ZERO when I try to start the music in Roon, and jumps to the next track after a little while and so on (everything further in Roon looks normal at first glance) A good friend of mine, also with a Lumin U2 (but the small Nucleus) has the same issue, but another good friend, who has a different brand of streamer, has no problem. I hope you can help me?
Best regards, Henk-Willem
Tell us about your home network
· Standard router from provider Ziggo with Netgear GS105 switch (Cat 7 cables)