As mentioned above, running the server on a Mac works fine.
Now I need to figure out why the NUC/ROCK isn’t performing.
Your statement was:
I thought you were running Linn Kazoo server on Mac. If you have already tried the Roon Server on Mac and it works, then I would suggest Windows (disable Energy Efficient Ethernet in network adapter advanced properties) or standard Linux on the NUC and retry.
Hi @anonymouse,
@wklie makes a good point above - and it’s definitely worth a try if you can.
We’d be happy to review a fresh timestamp as well, from the issue ROCK - feel free to share the date, time, and name of track and we’ll take another look.
Thanks! 
Thanks.
I now have the server running on Dietpi. (Tomorrow I have an additional ethernet switch arriving and will try a direct peer connection from NUC to linn but for now they are both on our normal Unifi ethernet.)
I have had a couple of short interruptions and on one occasion the player stopped.
I’ve sent some logs - at 12:18 the player stopped a couple of times when playing “Wholly Holy”. From my amateur look at the logs it seems something was reconnecting - I don’t think this is the core problem we are trying to address but could you take a look anyway? Thanks.
Hi @anonymouse,
Thank you for your report. Here’s what we can see in recent diagnostic logging across both RoonServer machines.
In short, our investigation largely corroborates the suspicion of other users: RoonServer does not receive data from Qobuz quickly enough to distribute it at 192KHz. This problem is systemic throughout logs, but only accumulates sufficiently to break playback under certain network conditions. The fact that Linn reveals the problem is largely incidental. All
Timeouts with RoonServer’s download service from Qobuz begin to accumulate with all higher-resolution files, including those at 96Khz. In nearly all cases, RoonServer recovers sufficiently for the buffer to remain ahead of playback.
At times when RoonServer is downloading multiple high resolutions files to the cache for distribution to multi-Zone playback, then timeouts begin to occur with distribution, as well. RoonServer is requesting missing packets from Qobuz, and it’s also re-sending missing packets to each Zone as required.
But bandwidth allocation to Roon’s various services begins to fluctuate at this time - similarly, network reachability changes begin to take down background services, like device identification.
As you suspected, this will draw CPU on the RoonServer machine; but there is no logged evidence of resource constraint causing the dropout.
Instead, the dropouts result from a broken pipe in the songcast TCP stream due to connection reset events on the network. We can’t rule out that there’s some performance ceiling on the NUC that might contribute to your symptoms. But in the evidentiary context of the timeouts - even with lower-quality files than 192Khz - we have to attend to the possibility that the network overhead isn’t sufficient for simultaneous download and uncompressed distribution of 192KHz files.
We haven’t asked for the precise model of 48-port switch, but I’m assuming it’s one of the layer-3 switches in Unifi’s series based on discussion above. If that’s the case:
Depending on the spanning tree implementation in this managed switch, it may be holding up ports temporarily while it waits to identify devices and determine their optimal path across the network. As @wklie, replacing this switch with a fully unmanaged switch is a useful test.
In the meantime:
Prioritize the DietPi or the ROCK, whichever you plan to use long-term, in your router Smart Queue settings. This may help with bandwidth allocation issues. If you haven’t already swapped DNS server, that’s worth a try as well. Try swapping the ethernet ports in use for the DietPi for those in use by the Mac.
Thank you!
Most helpful thank you. I will continue experiments.
Is there a specific symptom I should look for in logs which will show whether the problem is improving or worsening? That would be a lot more efficient than listening to an hour of music to see if I get dropouts 
It is a USW-48-POE which is a layer-2 switch. The documentation says not to turn on smart queuing with internet bandwidth above 300Mbps (mine is 500) but I will look further.
Beyond that there is a UXG-Pro gateway which is doing traffic analysis for security - I might also try turning the packet inspection etc off, although the UXG should have comfortably enough processing power.
I don’t know about this brand enough, but for other consumer routers it’s a really bad idea to use any QoS / bandwidth management / traffic monitoring features for the purpose of Roon network audio.
I think it’s safe to say that if a feature cuts the router (or switch) throughput measurably, it must be disabled regardless of whether the reduced throughput is still higher than the WAN (or uplink) bandwidth.
Did you change DNS yet? I would try this before swapping out any hardware.
UXG pro should be able to handle those without loss of bandwidth it can push through 3.5gps to with them enable . I don’t think your hardware is the problem. I have the UXG Max securiy on, packet inspection annd get 1120 to my router from the modem using the 2.5gb port. This is connected usw 16 port PoE switch and several other PoE switches down the line from it and it works fine.
Did you change DNS? I have found oddly that with Qobuz here in UK using Quad 9 as my DNS service has made it way better.
I had similar issues to you last year and all of sudden it cleared up so I assume was an issue their side or from my ISP. Was using Cloudflare then now using Quad 9 and solid for the time being.
Can I ask are you in the UK and using Virgin Media?
Yes I am. Virgin Media Business (not that that seems to make a difference).
I will see how it settles now I have the player and server on same mini switch - then will try DNS.
VM I think is the (our) problem not anything else. They are poor as an ISP, I have no choice if I want fibre but the service is up /down at best. I would try quad 9 as I have and over all the other DnS this has faired better.
Hi @anonymouse,
Diagnostics indicate you might have reconfigured your setup and migrated to a new RoonServer machine.
Have you had a chance to try reassigning the DNS server in the meantime?
Thanks for checking back.
I migrated to DietPi. I reconfigured so the Linn player and the NUC are sharing a small switch together.
All was going brilliantly … until after a day or two, I had several periods of dropouts. If you want to look at the logs, it was 16:03 (BMV1054, 1. Allegro) and 20:51 (Fields of Gold) on 17 December.
I have not been able to move the DNS yet because a range of other things on the network broke, but I can try again. However if we can be a little more scientific, do you know the domain name which Qobuz will use for streaming? If I know that, I can use “dig” to compare whether it differs between my DNS and other public DNSes.
Also if you can let me know what to watch for in the logs, I can leave the player running overnight and check in the morning whether there have been dropouts.
Qobuz url is
https://streaming-qobuz-std.akamaized.net/
Thanks. On native Virgin Media DNS that was resolving to 2.22.144.136; on 9.9.9.9 it resolves to 62.252.115.24; and on 1.1.1.1 it resolves to 23.73.139.25.
I’ve switched to 9.9.9.9, flushed DNS and using 62.252.115.24 I got dropouts within a couple of minutes. Significantly worse!
Use 8.8.8.8 for DNS
Oddly 9.9.9.9 has pulled a Virgin media ip address, the others are both akaimi servers.
Will try that today. I don’t want the whole network on 8.8.8.8 because of Google surveillance but can probably force the NUC there.
Aargh. Switched to 8.8.8.8 and (after DNS flushed) it now routes me to 187.3-253-62.static.virginmediabusiness.co.uk (62.253.3.187)
Dropouts galore. Unlistenable!
In the logs I can see:
12/19 13:10:53 Warn: [218] FTMSI-B-OE qo/7A232D96: poor connection kbps:8878.0 (min:17513.0)
...
12/19 13:10:59 Debug: [172] [prebuffer] sleeping in read -- this isn't good
12/19 13:10:59 Debug: [172] [prebuffer] sleeping in read -- this isn't good
12/19 13:10:59 Debug: [172] [prebuffer] sleeping in read -- this isn't good
12/19 13:11:00 Warn: [258] [songcastdirect] [Linn Klimax DS] time discontinuity. Expected 1, Got 2
1
I have found something even stranger. Dropouts seems to be able to be replicated on some specific tracks.
Although I don’t think that is the whole problem.
Specifically “Sinfonia” (the overture) on Le nozze di Figaro, conducted by Teodor Currentzis.
Interestingly the title of the album is appearing on Roon as “Wolfgang Amadeus Mozart : Le nozze di Figaro (Édition 5.1)”. And the dropouts earlier today were also on an Édition 5.1 album it turns out.
I see on the signal path that there is a down mixing 5.1->stereo. Perhaps that is failing?
Is there a way to block the 5.1 tracks from playing?