· I am experiencing freezes or crashes
· I am experiencing freezes or crashes
· Other
track skipping with all connectivity types and sources
Unifi wired and wireless network. U7Pro Access Points and Unify managed switches. Cat 5E and Cat6A cabling
I have experienced numerous skipped tracks. At first I thought it was a wireless and or Qobuz issue - there have been numerous threads about this on this board.
However, I have also experienced the same issue on my Wired network - on which I consistently get a 2.5GB/s connection to my Unifi Switch. So I figured it couldn’t be purely bad wifi.
Perhaps then it was the connection to from my NUC/ROCK server (direct connect to my Unify Switch) and Qobuz - but I have just experienced it whilst playing back a track from an audio file stored locally.
This track is CD quality (ripped originally from one of my own CDs). So not high data density. It is stored on the NUC/ROCK internal NVME V4 SSD (so very fast).
When I rewound via the Roon display, and replayed the same track, it played flawlessly. So no issue with the actual track data.
I noted the approx time on my Apple Watch at which it occurred (17:48 ) - which should hopefully be within +/- 1 minute of the time in the Roon Logs.
It was at the time playing the track to my WiiM Ultra endpoint via wifi (a strong wifi signal). I have the logs relating to this time period, which I can post here if necessary.
It may be unrelated, but I am also seeing this message consistently in the Roon UI:
It never manages to identify these 18 tracks (but the number changes occasionally). This has been going on for days.
But I don’t want to make this into a two-issue post - my main concern is the track skipping.
I am running the latest version of ROCK. My switch is connected direct to my Unifi Router and thence out to the internet. There is no connectivity issue with my internet connection.
I have extensive and in-depth network logs from the Unifi console - so I’m confident that there was no unusual network glitch at or close to the time this issue occurred.
Hello @Alister_Sibbald
Thank you for contacting Roon Support.
We have received the diagnostic data from your account and are currently reviewing it with our QA and R&D teams. Does the issue only affect one WiiM Ultra end device, or do other devices have the same issue?
All devices have the same issue - in the sense that they all exhibit skipping. I can’t be sure that they all display the same error message when they do. It is not consistently the same track - although often, when it starts, it will sometimes do it for a number of tracks - i.e. it skips one track then skips the next after attempting to play it, then. another and another until it sorts itself out.
The end devices I have experienced this on are:
1 - Mac mini M4. Wired 1GB/s connection via Cat5e to a 2.5GB/s port on my Unifi switch via a 1GB/s Unifi mini 4 port switch.
2 - Windows 11 mini PC (N95 CPU/16GB RAM/256GB SSD). Connected to he same Unifi mini 4 port switch as the Mac M4
3 - WiiM Ultra as per the original report
4 - iPad Air M2 connected via wifi.
I’m not sure what diagnostic data you have - but in the Log files (if that’s what you have), the skip happened whilst playing the track “Karmosin”. It started playing this track around 17:46 and skipped when it was somewhere in the middle of the track - before and/or not later than 17:48 as measured on my Apple Watch.
I then rewound to the track before Karmosin, then fast forwarded to Karmosin again - and this time through, Karmosin played in full with no glitches.
Let me know if you want me to send you the log file if you don’t already have it.
This may be of interest - before the skipping, the NUC/ROCK seemed to go out to the internet and download a lot of data:
The data download appeared to start around 17:15 - 17:20 (the data presentation here is averaged over 5 min periods)
Then started dropping between 17:45 and 17:50 - exactly the time period I experienced the skipping…
And by 17:55 it was back down to its base load and just ticking along until the next, even bigger download spike
The next download spike started around 19:35 - 19:40.
Speculating - could it be that there ROCK has gone off to the internet, downloaded a lot of data and then around 17:45 started some intensive processing of that data?
That’s an awful lot of data being downloaded - 1.76MegaBits per second average for around 30 minutes total implies around 400 MegaBytes in total. And then even more a couple of hours later. What is it doing?
If that processing had overloaded CPU or memory or I/O internally, it could conceivably have resulted in the skipping. But I don’t think I have access to this level of internal logging to be able to check this…
By the way - to be clear, this data is ONLY for the switch port the ROCK is on. There is nothing else on this port and I’ve filtered out all data relating to other ports.
But just to put this in perspective, here is the data for ALL internet traffic in and out of my house over the same sort of period:
Blue is download. Lilac is upload and yellow is latency
The vast majority of the traffic between the ROCK and the Internet appears to be Akamai.net (85% of all traffic) and “SSL/TLS” ( 15% it doesn’t tell me from/to location for this). All other traffic adds up to less than 1% combined. The 85%, 15% and 1% are rounded numbers - hence the 101% total.
To be clear - I wasn’t interacting with either the ROCK or the Roon UI at the time. I had set an album to play about 20 mins before and was just sitting listening to it. So it appears this spike of activity was due to some sort of internal process kicking off inside the ROCK of its own volition.
One final thing, whilst I remember. If the NUC is indeed overloading, it will likely do this on most installations, as this NUC is highly optimised for speed. It is the latest i7 CPU, with 16GB of very fast RAM, an internal V5 NVMe drive for the OS and another internal V4 NVMe drive for the music database. If Roon is overloading that, it will probably overload anything…
Here’s the traffic profile to/from the NUC/ROCK over the past week. The graph is smoothed compared to those above as it’s no longer being averaged over 5 minute intervals.
By the way - I inadvertently switched the NUC off on Friday - hence the lack of I/O on that day.
Hey @Alister_Sibbald,
Thanks for all the additional information! From your Roon Server logs, we can see the following errors occur, resulting in playback stopping:
Trace: [Lounge KEFs] [Lossless, 16/44 ALAC => 16/44] [100% buf] [PLAYING @ 2:00/5:10] Karmosin - Tord Gustavsen Trio / Tord Gustavsen / Harald Johnson / Harald Johnsen
Trace: [Linkplay Technology Inc. WiiM Ultra @ 10.1.2.146:42215] [raatclient] GOT [42] {"samples":22528,"status":"Dropout"}
Trace: [Linkplay Technology Inc. WiiM Ultra @ 10.1.2.146:42215] [raatclient] GOT [42] {"samples":20480,"status":"Dropout"}
Trace: [Linkplay Technology Inc. WiiM Ultra @ 10.1.2.146:42215] [raatclient] GOT [42] {"samples":22528,"status":"Dropout"}
Trace: [Linkplay Technology Inc. WiiM Ultra @ 10.1.2.146:42215] [raatclient] GOT [42] {"samples":22528,"status":"Dropout"}
Warn: [Lounge KEFs] [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
Trace: [Lounge KEFs] [zoneplayer/raat] too many dropouts. stopping stream
Info: [audio/env] [zoneplayer] All streams were disposed
Warn: [zone Lounge KEFs] Track Stopped Due to Slow Media Notice that the track buffer was at 100% before dropouts occurred and playback stopped. This tells us your ROCK isn’t struggling to obtain a connection to upstream services, but is more likely struggling to provide a smooth connection to your local devices within your local setup.
If possible, would you be able to temporarily simplify your network setup and get a direct Ethernet connection from your ROCK to your primary router, as well as one of your endpoints, with the same simplified connection?
Test playback to this single, hardwired endpoint, and see if you run into the same issues - we’ll be monitoring for your reply and results. Thank you! 
I can do that - but not this evening.
You seem to be assuming that the connectivity issues with the WiiM Ultra are due to issues with the network. This is possible - and as I have said, I’ll sort out that connectivity tomorrow.
But it is also at least possible that these connectivity issues are the result of internal software overloads within the ROCK code too. Have you eliminated this as a possibility?
Or is the request to simplify the networking a speculative one? I have a highly performant wired and wifi network and whilst this sort of thing is possible, I’d like to be sure that we have eliminated the other possibility too.
If we DO find that direct connected CAT6A “solves” the problem, have we actually solved anything at all? Will we then have to say to anyone experiencing this sort of thing that the “solution” is that they cannot use a very fast, reliable WiFi network for home audio - and have to use a wired network? Is that an acceptable “solution”.
A final question - when you say “direct connect to your router” - are you really saying you want me to bypass my main 16 port Unifi 2.5GB/s POE switch and go straight into one of the ports on the router itself? Are we really thinking that this sort of highly capable switch may be causing the issue?
As I have already mentioned, I get these track skips even when directly connected via Ethernet - albeit via two switches (see my message above) from both a Mac mini M4 and an N95 Windows 11 PC. Are you asking me to eliminate the switches in this connectivity?
I could move the NUC to sit next to my Mac mini and N95 Win 11 box, connected via the 4-port Unifi Gigabit ethernet switch to them and to the main router. Is that what you’re asking me to do?
Or do you want a direct Ethernet connection from the NUC to the WiiM? - although this would of course have to be via a switch too…
OK - as of approx. 13:30 today, the ROCK is connected via Ethernet (not WiFi) to the WiiM Ultra.
Specifically:
So, apart from traversing the backplane of the switch and a couple of RJ45 connectors, this is in effect a direct Gigabit Ethernet connection from the ROCK to the WiiM Ultra.
If the skipping is caused by network speed or latency issues, then it should not appear with this configuration.
I’ll sent up a multiple hour playlist at some point a bit later and get the ROCK playing it to the WiiM Ultra (with the speakers off). We can then see if we get any recurrence of the skipping.
However, my question still stands - if this solves the problem, as we thus saying that ROCK cannot be relied upon to replay without skipping on even a highly performant WiFi network such as the one I have?
I suspect relatively few Roon users have as high performance wifi as I have. (Wifi 7 MIMO, multiple hardwired access points)
Hello @Alister_Sibbald,
Thank you for these thoughtful questions — your reasoning is absolutely valid, and it’s clear you’ve invested a lot of time into understanding the behavior. Let me clarify a few key points so you know exactly why we’re asking for a simplified network test and what it can (and can’t) tell us.
We have already reviewed your ROCK logs for CPU, I/O, and memory pressure
From the diagnostic bundle:
In other words, from everything we can see inside ROCK, the system is not overloading itself and not falling behind in its processing pipeline.
The fact that the buffer was at 100% immediately before the dropouts is consistent with this — the Core was delivering audio perfectly fine right up until the data left the ROCK.
So at this point, the evidence points to the transport layer between the Core and endpoints, not internal ROCK performance.
This is not because we assume your Unifi network is “slow” — it’s the opposite.
When troubleshooting RAAT behavior, we try to reduce the number of variables to as close to a lab-controlled setup as possible. Even in extremely capable networks, there can be:
None of these require a “weak” network — they are simply characteristics of managed, enterprise-style hardware.
So the purpose of the test is not to suggest your network is inadequate — it is to remove all possible external variables and isolate whether the dropout originates before or after the data leaves ROCK.
If the issue still happens on a direct Core → router → endpoint chain, then we know the root cause must be inside ROCK or the endpoint.
If it stops happening, then something in the larger topology is interacting with RAAT.
Either outcome moves the investigation forward.
Roon supports WiFi — many thousands of users run stable setups over wireless. However, we are still recommending using a wired connection for the best performance.
When diagnosing timing-sensitive RAAT behavior, WiFi adds layers that are, by nature:
We are not moving toward a conclusion that your WiFi is unfit for Roon.
We are simply trying to get a clean data point that tells us whether WiFi is even a relevant factor.
To answer your question:
“Are you asking me to eliminate the switches?”
For this one test: yes, exactly.
Please temporarily arrange:
ROCK → (Ethernet) → Router → (Ethernet) → One endpoint
No intermediate switches, no APs, no mesh hops.
Any endpoint is fine — whichever is physically easiest.
This is not meant as a permanent solution.
It is purely a diagnostic step, so we can say confidently:
Both answers are actionable for us.
Those are normal background activity:
They can look “big” on a graph, but they neither saturate the CPU nor interfere with the audio pipeline — which is strictly prioritized.
The logs also show no RAAT starvation during those spikes, so they are not the cause of the skip.
Once you have the simplified wired test results, we can correlate them with the internal logs that will be collected and continue the investigation with R&D.
Thank you again for the level of detail and the care you’re putting into this — it genuinely helps us move faster.
Vadim,
Thank you for your extensive and thoughtful answer. I Understand very well now why you ask what you did.
Currently, as outlined above, I have both the ROCK and the WiiM Ultra plugged into my 16 port switch. My main Router (a Unifi UCG Max) is also plugged into it. I understand now that this is not the topology you’re looking for.
A little later, when I finish work, I’ll rearrange the wiring in the Network rack and plug both the ROCK and the WiiM Ultra direct into the UCG Max. However, in my particular case, I don’t think that will eliminate much, if any of the traffic types you mention. My UCG Max router is ALSO my network management console. It issues IP addresses and generates all the sorts of management packets you refer to. I can’t disconnect it from my switch, as that would eliminate my network.
So I will eliminate the switch from the wiring, but unfortunately, that will not eliminate the sorts of “enterprise” management packets and traffic you mention.
Update:
Rewired ROCK and WiiM ultra straight into ports on my UCG Max around 14:56. It took them a few minutes to sort themselves out with the correct IP addresses, but they had both re-acquired their correct IPs by 15:08.
Rock is 10.1.2.13 - it has a 2.5GB connection
WiiM Ultra is 10.1.2.212 - it has a 100MB connection (limited by the Ethernet capability of the WiiM)
I’ll set up that playlist I referred to and kick it off as soon as I can and annotate the time here.
Sounds good @Alister_Sibbald we’ll be monitoring for your reply and results. Thank you!
Vadim & Benjamin,
I started playing music through the wired WiiM Ultra at about 16:35.
I have been listening pretty much non-stop since then. It is now 19:20.
I’ve left music playing on the WiiM Ultra using Roon Radio - which I think should keep it going pretty much indefinitely? The volume on the WiiM is muted (Not paused - I’ve confirmed the music progress timer is progressing and it is moving from one track to another.
I’m happy to leave it like this all night and as long tomorrow as practicable. Let me know when you have enough data for your needs.
I’d be very surprised if we saw any skips - if the skips really are caused by network failure/latency etc. There shouldn’t be any issue with that now. I experienced no skips at all during this 3 hour listening window. But OTOH - I’m the only person in the house at the moment. Normally, there are 5 of us and all making use of the Wifi for either work or entertainment. So the network has been unusually quiet during this time.
If, after this experiment, you want me to change the setup to establish what was going on when it was WiFi connected, I’d be happy to assist. I have extensive diagnostic data available for my network. All components of it are managed Unifi devices and report back to the management console.
Ultimately, playback over wifi from Apple Music, or Qobuz Connect, or Spotify works fine - without these noticeable track skips or glitches. So it seems something in the error recovery mechanism of Roon is less than ideal.
If the Wifi is causing these glitches, it surely must be doing so in the case of all the other streaming protocols. But they recover from it in a manner that is not as noticeable or irritating as the way Roon does it.
It would be good to assist Roon to get to a similar level of user experience in this matter - as it is way ahead in user experience in most other aspects…
Some further thoughts on why Roon’s error recovery here is less user-friendly than some others:
It appears that, on detection of connectivity issues between Roon Server and the Roon endpoint, the approach has been to skip to the next track. This seems to be an illogical response to the issue for two main reasons:
There is potentially another issue here:
The the only time the Roon endpoint needs to stop a particular track playing is when the end point runs out of data in its buffer. With a big enough buffer, it could keep playing for minutes - or longer - without any further refresh from the server. Yes, this might play havoc with attempts to synchronise playback between different endpoints - and yes, it may make the endpoint unresponsive to pause/skip commands from a remote UI. But I - and I think most people - could live with the UI unresponsiveness in preference to this skipping approach. The synchronisation of multiple endpoints is detectable - and this behaviour of letting each endpoint “do its own thing” could be changed in that case. But I suspect this synchronisation case is much less common than the independent end point case. and people doing “critical listening” are probably listening to a single end point.
So - if my analysis of what is happening is correct - my proposal would be to change the recovery mechanism to address the actual problem being experienced. In this case, allow the end point to pause itself if it runs out of buffer and signal that to the server (and signal when it’s running low on buffer - although I imagine it does that already).
The system should not be trying to skip to the next track in response to a comms link failure. That response is only valid when the current track being played is definitively inaccessible - which is not the case here.
Hi @Alister_Sibbald,
Thanks for the follow-up!
I highly suggest sharing your thoughts over in the Feedback category - that way it’ll be properly tracked from our product team.
I’m glad to hear you’ve managed to remove the playback issues when using a cabled connection. Certainly, let me know if you’re still having issues you’d like to continue troubleshooting. 
I’m not sure I have resolved anything. I wired it up because you asked me to so you could investigate further.
Have you done any further investigations? I left it running for. number of days on Roon Radio, so there should be extensive logs available for you.
Hello @Alister_Sibbald,
Based on the wired-session logs, we can confirm that neither ROCK nor the WiiM Ultra is responsible for the behavior you’ve been seeing. With a clean transport path, RAAT remains stable for days without a single underrun or stall. This strongly suggests that the issue appears only when the playback path includes the wireless segment of your network.
To help us pinpoint the exact trigger, could you clarify one detail:
Which device is normally on WiFi in your everyday setup — the ROCK, the WiiM Ultra, or both?
As a next step, please return just one component (preferably the WiiM Ultra) back to its usual WiFi position and run the same playback test for a bit. This will allow us to compare the WiFi logs directly against the clean wired baseline and identify where the timing instability is introduced.
You don’t need to change anything else in your topology — just place the WiiM back where it normally lives and let it run as you did before.
Once we have that comparison, we can narrow down the specific wireless behavior that’s causing RAAT to abort the stream.
Looking forward to your update!