Playback and Interface Freezing with "No Audio Devices Found" Error (ref#8NX1XX)

Adrian_Berry · June 9, 2026, 12:56pm

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

· Playback stops slowly; the sound goes 'crackly'maybe pauses, continues then stops on. teh Roon Server followed several seconds later by teh Ropieee. The Roon Remote interface freezes then get message "No audio devices found". I have also seen screens that say there is nothing in my library and the there are no Live Radio stations. Eventually it all recovers and I can continue playing.
I have had issues with Live Radio dropping out for years now but this is different. It happens with Live Radio, streaming from Qobuz or from music stored in teh Roon Server.
Roon setup:
Roon Server version 2.67 (build 1661) running on an Intel NUC, this also has a Douk Audio USB to SPDiff interface supplying one sound system. Server has been up for 3 days, 14 hours, 18 minutes, 54 seconds during which time I have seen this problem many times.
Ropieee version 2.60 (build 1501) running on a Raspberry Pi Raspberry Pi 4 Model B Rev 1.2 2Gb RAM with a Douk Audio USB to SPDiff interface supplying another sound system
Roon Remote version 2.67 (build 1661) running on macOS Tahoe 26.51 on a Mac Studio M1
I have zipped the Roon Server log files and can upload if needed

Tell us about your home network

· Router is a BT Home Hub 2 supplying Gigabit ethernet, a Netgear 32 way switch, a 4 way hub. Entire system is hardwired with CAT5e cable

benjamin · June 11, 2026, 6:23pm

Hey @Adrian_Berry,

Thanks for writing in and for sharing your report, and I’m sorry to hear you’re suffering from playback issues!

We were able to take a closer look at a fresh diagnostic report from your Roon Server, the behaviour you describe, crackle, brief pause, recovery, with the Ropieee zone dropping a few seconds after the local zone, and the Remote flashing “no audio devices / empty library / no Live Radio” before recovering, is the signature of the Roon Server process briefly freezing as a whole, not a per-zone or per-cable fault.

When the server process stalls, every output it feeds starves at once (local Douk USB first, networked Ropieee a beat later as its buffer runs dry), and the control/UI connection goes unresponsive, which is why the Remote momentarily thinks there are no devices, no library and no radio.

With that, the strongest signal in the logs is garbage-collection (GC) stalls that get worse the longer the server runs:

A stop-the-world pause of one to three seconds while audio is streaming will empty the RAAT buffer, give you the crackle-then-stop, then recover once the process resumes, precisely your description. It also explains two things you mentioned: that it has worsened recently, and that it eventually recovers on its own. The fact that the server had been up 3 days 14 hours when you observed it being bad lines up with the upward GC trend.

The good news here is that our development team is on the cusp of releasing improvements to this exact area, so a longterm fix is headed your way soon.

In the meantime, see if the following help at all:

Restart the Roon Server and note whether the problem disappears, then creeps back over a few days. If a fresh process is clean and it degrades with uptime, that confirms the GC/uptime pattern above. This is the single most useful diagnostic and a practical stopgap (even a scheduled nightly restart of the NUC would mask it).

Simplify the DSP/upsampling temporarily. Your config upsamples everything to 96 kHz via custom sample-rate rules plus parametric EQ. That's not the root cause, but it raises per-second CPU and allocation load, which makes GC pauses bite harder. Try disabling sample-rate conversion (and the PEQ) for a listening session and see if the dropouts lessen, a useful data point even if you want the DSP back afterwards.

Thanks, Adrian!

Adrian_Berry · June 17, 2026, 1:55am

Hi, thanks for this response.

I have now checked over my entire ethernet wiring system. I did find, and have fixed, some dodgy connections but they were not in the path to any of the Roon items. I have also rewired so that my Roon Server is connected directly to my BT Smart Home 2 router and the Raspberry Pi endpoint is now connected directly to my NetGear Switch, which is connected to the router. Also everything has been rebooted and is absolutely running the latest version of all software.

The result of these changes is that Roon Live Radio will play just on the Roon Server for over a day. It will also for a long time with the Kitchen Raspberry Pi in the same zone. But the system does now seem to stop in the early morning when running the two in a grouped zone.

vadim · June 22, 2026, 1:31pm

Hi @Adrian_Berry,

Thank you for the update and for all the work you’ve put into cleaning up your network infrastructure; it is great to hear that the system is significantly more stable now.

While it is promising that the playback is lasting much longer, “early morning” can be a very broad window of time. To help us determine if these remaining grouping dropouts are still related to the same garbage-collection (GC) process or if they are now being triggered by a specific network or power-saving task, we need to pinpoint the exact moment it happens.

The next time the system stops while running your grouped zones, please:

Note the exact local time and date (e.g., June 23 at 5:12 AM).
Reply here with that timestamp.

With that specific time, we can pull a fresh diagnostic report and check the server logs to see exactly what the Roon process is doing at that moment - whether it is hitting another GC stall or if there is a different process (like a scheduled backup or a network-level refresh) occurring at that time.

Adrian_Berry · June 22, 2026, 6:59pm

Hi, I have now made some further changes to my network. All the Roon devices are now connected directly to a new 1Gb Ethernet switch which has a direct connection to the BT Router. This should minimise any network traffic sharing the connections with the Roon traffic

It has now been running for 1 hour 36 minutes. I’ll let you know what happens.

Adrian_Berry · June 23, 2026, 8:46am

The system started stopping this morning at Local 06/23 02:04:02.

06/23 01:04:02 [Local 06/23 02:04:02] Trace: [raatserver] [HIFI DSD] lost client connection. Retrying(1)
06/23 01:04:02 [Local 06/23 02:04:02] Info: [raatserver] [HIFI DSD] connecting (attempt 1)
06/23 01:04:02 [Local 06/23 02:04:02] Info: [transport] destroyed zone Roon server + Kitchen Pie was playing? True
06/23 01:04:02 [Local 06/23 02:04:02] Trace: [zone Roon server + HIFI DSD] Suspend

I’ve just checked and found a setting in the Kitchen Pie Ropieee that reboots it at 02:04. Which probably explains this disconnect! I’ve now turned the auto reboot off completely.

So I’ll set it all running again and see what happens

benjamin · June 24, 2026, 6:02pm

Excellent findings @Adrian_Berry!! Keep us posted on if that helps with the stoppage.

Adrian_Berry · June 26, 2026, 9:57am

After about 2 1/2 days of continuous playing Planet Rock in Live Radio, the system stopped this morning. This is where it went wrong:

06/26 04:58:58 [Local 06/26 05:58:58] Trace: [Kitchen Pie] [LowQuality 22.8x, 24/48 MP3 => 24/96] [PLAYING @ 4043:00] AD 6
06/26 04:58:59 [Local 06/26 05:58:59] Trace: [raat_ll/client] [HIFI DSD] OnDisconnected: BeginRead ead count is 0
06/26 04:58:59 [Local 06/26 05:58:59] Trace: [raatserver] [RaatServer ropieeeKitchen @ 192.168.1.253:9200] lost client connection. Retrying(0)

Update: After posting the above, I set it playing Planet Rock again. Its just stopped again!

06/26 10:22:35 [Local 06/26 11:22:35] Trace: [Kitchen Pie] [LowQuality 23.4x, 24/48 MP3 => 24/96] [PLAYING @ 25:03] Born To Run - Bruce Springsteen
06/26 10:22:35 [Local 06/26 11:22:35] Trace: [raat_ll/client] [HIFI DSD] OnDisconnected: BeginRead ead count is 0
06/26 10:22:35 [Local 06/26 11:22:35] Trace: [raatserver] [HIFI DSD] lost client connection. Retrying(1)

vadim · June 26, 2026, 10:32am

Hi @Adrian_Berry,

Thank you for the update and for running the system for 2.5 days - that’s a very useful data point.

We have now reviewed the logs from this morning’s stop in detail.

The good news is that the Roon Server itself did not freeze or stall - its log runs continuously through the event with no gaps, and memory and GC activity were within normal range at the time.

The disconnect originated on your ropieeeKitchen device - the Pi at 192.168.1.253 cleanly closed its TCP connection to Roon Server at 04:58:59 UTC. Roon Server then tried to reconnect five times over four seconds and received “Connection refused” each time, meaning the Pi was reachable but its RAAT server port was not yet accepting connections. The RAAT server on the Pi came back up at 04:59:03 and Roon Server reconnected successfully - consistent with a brief process restart on the Pi side completing in about four seconds.

To find out why the RAAT server restarted on the Pi, we need the RoPieee system logs from the device itself.

Open the RoPieee web interface in a browser - usually at http://192.168.1.253
Go to the Feedback or Log section and export the system logs
We are looking for any RAAT server restart, watchdog event, or USB/ALSA error around 05:58:59 your local time on June 26

One thing worth checking in particular is the HIFI DSD USB DAC connection on the Pi - a USB audio error at the driver level can cause the RAAT server to restart.

For help with RoPieee specifically, please head over to - Audio Gear Talk > RoPieee - where the community and RoPieee users will be best placed to help you dig into the Pi-side logs and get to the bottom of it.

Adrian_Berry · June 27, 2026, 9:22pm

Ok, I did as suggested and created a thread How do I access the RoPieee system logs?

Harry has now reviewed the RoPieee log file and says this:

pockfishHarry ten BergeRoPieee Author

1h

And this log has captured the issue at hand?

Your logs do show something I normally don’t see (or I never noticed it)

06/27 15:02:51 Trace: [RAAT::HIFI DSD] [drift] update remote clock -401287765215us at local clock 30578018us error=-585us correction=0us neterror=-585us (-56 samples @ 96000hz)
06/27 15:02:53 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] got clock sync response, offset= -401318343.44947 rtt= 0.695
06/27 15:02:53 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] got clock sync response, offset= -401318343.34068 rtt= 0.412334
06/27 15:02:53 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] got clock sync response, offset= -401318343.32349 rtt= 0.418778
06/27 15:02:53 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] got clock sync response, offset= -401318343.5302 rtt= 0.757611
06/27 15:02:53 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] got clock sync response, offset= -401318343.40419 rtt= 0.484223
06/27 15:02:53 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] synced to master clock. offset=-401318343.34068 nominal remote time 401350934540845 rtt 0.412334
06/27 15:02:53 Trace: [RAAT::HIFI DSD] [drift] update remote clock -401285752120us at local clock 32591220us error=-691us correction=0us neterror=-691us (-66 samples @ 96000hz)
06/27 15:02:55 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] got clock sync response, offset= -401318343.50445 rtt= 0.659
06/27 15:02:55 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] got clock sync response, offset= -401318343.44447 rtt= 0.48763
06/27 15:02:55 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] got clock sync response, offset= -401318343.43239 rtt= 0.469963
06/27 15:02:55 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] got clock sync response, offset= -401318343.51786 rtt= 0.601481
06/27 15:02:55 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] got clock sync response, offset= -401318343.47846 rtt= 0.615408
06/27 15:02:55 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] synced to master clock. offset=-401318343.43239 nominal remote time 401352952642744 rtt 0.469963
06/27 15:02:55 Trace: [RAAT::HIFI DSD] [drift] update remote clock -401283734202us at local clock 34609229us error=-783us correction=0us neterror=-783us (-75 samples @ 96000hz)
06/27 15:02:57 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] got clock sync response, offset= -401318343.51662 rtt= 0.576629
06/27 15:02:57 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] got clock sync response, offset= -401318343.50295 rtt= 0.523666
06/27 15:02:57 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] got clock sync response, offset= -401318343.47191 rtt= 0.396519
06/27 15:02:57 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] got clock sync response, offset= -401318343.54074 rtt= 0.520574
06/27 15:02:57 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] got clock sync response, offset= -401318343.4964 rtt= 0.497092
06/27 15:02:57 Trace: [RAAT::HIFI DSD] [lua@0x7f580011c8] [192.168.1.98:44678]  [roon] synced to master clock. offset=-401318343.47191 nominal remote time 401355001176742 rtt 0.396519
06/27 15:02:57 Trace: [RAAT::HIFI DSD] [drift] update remote clock -401281685747us at local clock 36657724us error=-823us correction=0us neterror=-823us (-79 samples @ 96000hz)

Maybe you should contact Support about this."

I am guessing at what is going on here but what do you think it means? Whatever, I’m not sure what I can do about it!

benjamin · June 29, 2026, 9:57pm

Hi @Adrian_Berry,

Thanks for the additional information and RoPieee log snippet, and to Harry for flagging the drift, it’s a useful clue.

Quick summary of where we are: the June 26 server logs cleared the Roon Server itself (it ran continuously through the stop with normal memory and GC), so the earlier garbage-collection theory is off the table. The remaining issue is on the endpoint/RAAT side.

What Harry’s log shows: the clock sync to the master is healthy, but the drift error on the Pi is climbing steadily, while the correction stays at 0. In short, the Pi’s audio clock is gradually drifting from the master and RAAT isn’t pulling it back. Left unchecked, that eventually empties the buffer and drops the connection, which fits your “plays for ages, then suddenly stops” pattern. The likely source is the USB audio path, i.e. the Douk USB-to-SPDIF interface, since the clock is tied to that device.

Three things that would confirm it:

Grab a RoPieee log that spans an actual stop (Harry’s snippet looks to be from normal playback, not a failure) and note the exact local time, so we can match it to a fresh server diagnostic.
Run the HIFI DSD zone ungrouped for a long stretch. If ungrouped is solid and only grouped fails, the issue is specifically cross-zone clock sync.
If possible, try a different USB device on the Pi, or the DAC directly without the Douk converter. If the stops vanish, that points right at the Douk interface.

That should get us from theory to a confirmed cause. Looking forward to the results.

Adrian_Berry · June 29, 2026, 11:59pm

This is not possible because RoPieee now does not allow mere mortals to access the log files. I understand that RoPiee is now configured as an ‘Application’, whatever that means, and log files are only accessible to Harry if the user clicks on the ‘Send Feedback’ button in the Advanced Features page and sends Harry the resultant reference number. Which is what I did.

Ok, I’ve ungrouped the system and set the Kitchen RoPieee with the HiFi DSD playing Planet Rock. Will post back later and let you know what happens.If possible, try a different USB device on the Pi, or the DAC directly without the Douk converter. If the stops vanish, that points right at the Douk interface.

The Kitchen RoPieee is feeding a Meridian G91A via the Douk USB to S/PDif converter. The Meridian does not have a USB input, if it did then I wouldn’t need the Douk .
I have another couple of Douk USD-S/PDiff interfaces. One of them is connecting my ROON Rock Server to a Meridian 562.V2 which hasn’t been a problem. So far!. So if 2) fails I’ll try a different Douk.

vadim · June 30, 2026, 10:57am

Hello @Adrian_Berry,

Thank you for following up, and thanks to Harry for digging into this.

What this log shows is your clock drift correction stuck at zero while the error value keeps growing (-585us, then -691us, then -783us, then -823us, climbing steadily over just a few seconds). Normally RAAT continuously nudges the clock to keep it in sync (correction would show non-zero values pulling the error back down), but here it’s not applying any correction at all - so the drift just keeps accumulating unchecked.

Left to grow, this drift eventually exceeds RAAT’s tolerance and forces a stream restart - which is exactly the “play for ages, then suddenly stop” pattern you have been seeing, and matches the TCP disconnect/reconnect we found in the Roon Server logs at the same time.

This points specifically at the clock/timing behavior of the audio path on the Pi - most likely the Douk USB-to-SPDIF interface, since the system clock RAAT is trying to sync against is tied to that device’s driver.

Given you have another Douk unit working fine on a different Meridian setup, it would be worth swapping the Kitchen Pi’s Douk interface with that one temporarily to see if the drift pattern follows the specific unit or stays with the Pi. If the drift disappears with a different interface, that would confirm a fault with this specific Douk device.

Adrian_Berry · June 30, 2026, 1:09pm

Ok, I have swapped the Douks between the Roon Server and the Kitchen RoPieee. They are running independently playing different radio stations.Will post when something happens.

Adrian_Berry · June 30, 2026, 5:49pm

Both zones just stopped playing simultaneously. Looks like it started going wrong here:

06/30 17:27:20 [Local 06/30 18:27:20] Warn: [Kitchen Pie] [zoneplayer/raat] long rtt sync HIFI DSD: realtime=17097578160455 rtt=51920us offset=-11715041us delta=-51787us drift=-95066us in 17096.92712325s (-5.560ppm, -20.018ms/hr)
06/30 17:27:20 [Local 06/30 18:27:20] Debug: [easyhttp] [43860] POST to https://api.roonlabs.net/roonmobile/1/cores/announce returned after 1752 ms, status code: 200, request body size: 1 KB
06/30 17:27:21 [Local 06/30 18:27:21] Debug: [easyhttp] [43861] GET to https://porttest.roonlabs.net/1/myip returned after 1966 ms, status code: 200, request body size: 0 B
06/30 17:27:22 [Local 06/30 18:27:22] Info: [mobile] GOT HTTP API /hello
06/30 17:27:23 [Local 06/30 18:27:23] Warn: [Roon server] [zoneplayer/raat] long rtt sync HIFI DSD: realtime=16996900825230 rtt=50668us offset=-164270180us delta=-50549us drift=-156521us in 16996.33104345s (-9.209ppm, -33.153ms/hr)
06/30 17:27:23 [Local 06/30 18:27:23] Warn: [Kitchen Pie] [zoneplayer/raat] long rtt sync HIFI DSD: realtime=17100667146492 rtt=51476us offset=-11714402us delta=638us drift=-94428us in 17100.53470155s (-5.522ppm, -19.879ms/hr)

This is followed by what looks to me, like the system trying to reconnect itself. Then I see the connection to the Kitchen RoPieee (192.168.1.253) being refused:

06/30 17:27:27 [Local 06/30 18:27:27] Debug: [raat/tcpaudiosource] connecting to 192.168.1.253:41039
06/30 17:27:27 [Local 06/30 18:27:27] Trace: [radio/library] got location GB
06/30 17:27:27 [Local 06/30 18:27:27] Error: [raat/tcpaudiosource] connect failed: Connection refused
06/30 17:27:27 [Local 06/30 18:27:27] Warn: [raat/tcpaudiosource] disconnecting + retrying
06/30 17:27:27 [Local 06/30 18:27:27] Debug: [raat/tcpaudiosource] disconnecting
06/30 17:27:27 [Local 06/30 18:27:27] Debug: [raat/tcpaudiosource] connecting to 192.168.1.253:41039
06/30 17:27:27 [Local 06/30 18:27:27] Error: [raat/tcpaudiosource] connect failed: Connection refused

The Kitchen RoPiee now has the Douk USB to S/Pdiff that was previously connected to the Roon Server. So either it’s a problem with the Kitchen RoPiee or both Douks? I spotted that the Douks are different vintages, The one that used to be attached to the Kitchen RoPieee has aUSB C connector whereas the one that used to be connected to the Roon Server has a micro-USB connector so is likely older.

benjamin · June 30, 2026, 6:56pm

Hey @Adrian_Berry,

Thanks for chasing this down with Harry on the RoPieee side, and for the patience through all the rewiring and testing.

That said, the fresh server logs we’ve reviewed do point somewhere specific, and it builds on what @vadim found about the disconnect originating around the Pi.

Looking at the latest stop, the failure is preceded in the same second by a “network reachability changed” event on the Roon Server. That event forces the server to re-initialise its whole network stack at once, account re-auth, streaming-service token refresh, push reconnect, and a full re-discovery of audio zones, and during that window every audio connection is dropped and retried. The “connection refused” retries against the Kitchen Pi are a symptom of that reset, not the trigger.

The important detail: this isn’t random. The “network reachability changed” event is firing every single day at almost exactly 05:27 and 17:27, twelve hours apart, and it shows up that way across every log file from June 23 onward. It also hits the server’s own local output (the Douk on the NUC at 127.0.0.1), not just the networked Pi, in the same instant. A restart on the Pi can’t drop the server’s own loopback output, so something at the network layer on the server’s side is briefly flapping the interface on a fixed 12-hour timer. The morning event usually goes unnoticed simply because nothing is playing at 05:27.

A clean 12-hour cycle like this most often comes from a DHCP lease renewal (a 12-hour lease is common on consumer routers, and the BT hub is a likely source), or a scheduled task on the NUC itself.

Two things would let us confirm it:

On the BT router, check the DHCP lease time, and assign the Roon Server (the NUC) and the Kitchen Pi static IPs or DHCP reservations. If the dropouts stop recurring at 05:27 / 17:27 after that, we’ve found it.
Next time it stops, or just by checking the Pi logs around 17:27 today, see whether the RoPieee also logged a network blip at that exact moment. If it did, that nails it down to a network-wide event rather than anything specific to the Pi or the Douk.

If it turns out not to be DHCP, the next place to look is a scheduled task on the NUC, so on the server it’s worth running ‘systemctl list-timers’ and checking cron for anything lining up with 05:27 / 17:27, plus any VPN with a 12-hour rekey.

Worth adding: you mentioned the two Douk interfaces are different vintages (one USB-C, one micro-USB). Given the failure hits both the Pi and the server’s local output simultaneously, the Douks are very unlikely to be the cause here, so I’d hold off on swapping them until we’ve ruled out the network event.

Thanks again, this is a good lead, let’s confirm the DHCP angle first.

Adrian_Berry · June 30, 2026, 8:32pm

I have just checked the router’s DHCP lease time. It is set to 1 day 0 hours.

I have also fixed the IP addresses for the Roon Server and the Kitchen RoPieee at 192.168.1.98 and 253 respectively.

Lets see what happens now

Adrian_Berry · July 1, 2026, 12:09am

I am just checking with the router what it thinks the Lease Time Left is for the Roon devices.

At 01:04:29 local time, the Roon Server has 00:17:24:50 and the Kitchen Ropieee has 00;20:32:21 left.

That doesn’t look consistent with the 12 hour theory for 2 reasons; Both devices have more than 12 hours left, the expiry times do not line up with the 05:27 / 17:27 times.

Adrian_Berry · July 1, 2026, 9:15pm

Stopped again. According to the Roon Server log file, it went wrong about here:

07/01 17:27:27 [Local 07/01 18:27:27] Trace: [raat_ll/client] [HIFI DSD] OnDisconnected: BeginRead ead count is 0
07/01 17:27:27 [Local 07/01 18:27:27] Warn: [raat/tcpaudiosource] send failed: Broken pipe
07/01 17:27:27 [Local 07/01 18:27:27] Warn: [raat/tcpaudiosource] disconnecting + retrying
07/01 17:27:27 [Local 07/01 18:27:27] Debug: [raat/tcpaudiosource] disconnecting
07/01 17:27:27 [Local 07/01 18:27:27] Debug: [raat/tcpaudiosource] connecting to 192.168.1.253:40773
07/01 17:27:27 [Local 07/01 18:27:27] Error: [raat/tcpaudiosource] connect failed: Connection refused

And then it fails to reconnect.

Adrian_Berry · July 5, 2026, 5:10pm

Kitchen RoPieee stopped again this afternoon.

07/05 14:56:48 [Local 07/05 15:56:48] Trace: [HIFI DSD] [raatclient] SENT [14]{“request”:“end_stream”}

Seems that both Douk USB to S/PDIF converters are having problems