Roon randomly skips to the next track during playback (ref#C69HV6)

Support
1

What best describes your playback issue?

· Music stops playing unexpectedly

What type of Zone is affected by this problem?

· *Network Zones* are affected.

Is the affected network Zone connected with Ethernet or WiFi?

· WiFi

Does the issue affect all file formats?

· The issue affects *multiple/all* file formats.

Does the issue happen with local library music, streaming service music, or both?

· *Only streaming* music is affected.

Please select the streaming service(s) with which you're encountering playback problems.

· TIDAL

Have you tried logging out and back in again to your streaming service in Roon Settings?

· Logging out and back in had no impact, the issue remains

Do you have an approximate timestamp of when the issue last occurred?

· 6/14/26 12:12pm PST and 12:14pm

What are the make and model of the affected audio device(s) and the connection type?

· Wired ethernet KEF LSX II x2 and KEF LS50 W2, WiFi Nest Audio x2

Describe the issue

Roon occasionally randomly skips to next track

Describe your network setup

Mac mini Roon Core, TP-Link Deco mesh, 1Gbps Spectrum Internet

2

Hey @Raul_Acevedo, welcome to the community.

Random track skipping on streaming playback can come from either the network path to the endpoint or an issue in the TIDAL handoff, so we’ll want to separate those two pieces.

Since your affected zones are on WiFi, let’s start by checking two things: first, whether the skips happen on all of the listed endpoints or only one of them, and second, whether the issue appears in the Networking Best Practices areas we care about most, especially if there are any WiFi-only hops between your Roon Server, mesh nodes, and the endpoints.

We’ll also want a fresh timestamp the next time it happens. We will enable diagnostics on your account, and when it occurs again, please note the exact local time, date, and the track playing, then let us know here so we can review the playback logs around that moment.

If you can, send over whether the skips are limited to one zone or show up across all four of the devices you mentioned. That will help us decide whether we’re looking at a zone-specific issue or something broader in the network path.

3

Issue just happened at 4:05pm PDT.

This happens on a Google Chromecast group involving all the speakers I mentioned above; the KEF speakers and Mac mini Roon Core are all wired ethernet to Deco mesh pods in their respective rooms, because I’ve had issues with KEF WiFi reliability in the past. The two Nest Audios are WiFi, with “Mesh Technology” disabled and tied to the 5 Ghz band. All the speakers, WiFi or ethernet, and the Mac mini Roon Core, have reserved IPs.

4

Happened again at 10:12am PDT.

Note this doesn’t happen on Spotify streaming to the same Chromecast group, and I don’t have issues streaming 4K content through my Apple TV (wired to the same Deco mesh pod as my KEF LS50 W2).

5

Again at 11:11am PDT.

6

Hey @Raul_Acevedo — thank you for the precise timestamps; they made it possible to pinpoint the exact cause.

The logs confirm that the skips are triggered by your Google Cast group (zone “The Ocean”) invalidating its Cast media session mid-playback. At each reported skip time — 10:12am and 11:11am on June 16 — the Cast receiver returned an INVALID_MEDIA_SESSION_ID error to Roon’s sender. When that happens, Roon treats the active track as unplayable and moves to the next one, which is what you’re experiencing as a random skip. The TIDAL side is healthy — stream requests succeed normally and the next track begins within milliseconds.

This error originates in the Google Cast layer, not in Roon or TIDAL. It typically happens when the Chromecast group’s internal media session is reset by the group coordinator — usually triggered by one of the group members dropping its connection even briefly.

We also see that your two Nest Audio speakers (Nest-Audio-969c... and Nest-Audio-a809...) are logging repeated TLS authentication failures against the Deco mesh every night between 2–4am. This is a strong signal that those speakers have ongoing connectivity instability on your network that likely underlies the daytime Cast group resets.

A few things to try:

  1. Test without the Nest Audios in the group. Create a Chromecast group in Google Home with only the KEF speakers (all wired) and play TIDAL through that group in Roon. If the skips stop, the Nest Audio WiFi connection is the weak link causing the group to reset.
  2. Check which Nest Audio is the group leader. In a Chromecast group, one device coordinates the others. If a WiFi device is the leader, a momentary disconnect resets the whole group’s session. You can try reordering devices in the Google Home group settings so that a wired KEF device leads — though Google doesn’t always honor this directly.
  3. Improve Nest Audio signal. The nightly TLS failures suggest marginal 5GHz coverage. Try moving a Deco node closer to the Nest Audio speakers, or try temporarily switching them to 2.4GHz to see if stability improves.
  4. Dissolve and recreate the Cast group. In Google Home, delete the “The Ocean” group and recreate it fresh. This clears any stale group coordinator state.

Let us know which of these you try first and whether the skips continue — ideally with timestamps if they do.

7

I can’t see a way to reorder the devices in the Chromecast speaker group, but I assume the “leader” is the IP under Roon → Settings → Audio → Other network devices → “The Ocean” Chromecast streaming, is that correct? If so it’s the ethernet KEF LSX II in the bedroom.

I switched the Nest Audios to 2.4 Ghz, the signal strength went up in the Deco app, so hopefully that helps.

I also recreated the Chromecast group.

I’ll see if this works, if it still skips I’ll let you know and try without the Nest Audios.

8

Happened again at 5:42pm PDT. :frowning:

9

I created a new KEF-only group called “KEF Group”, without the Nest Audios, and it just skipped at 7:07pm PDT.

10

Lastly… Note this has never happened on Spotify streaming to the same speaker group, even if it’s the same playlist transferred to Tidal via Soundiiz.

11

Hey @Raul_Acevedo, thanks for the precise timestamps - they matched the logs exactly on all four events.

What the logs show

Every skip follows the exact same sequence. Here is the pattern from the 6/16 10:12am PDT event as an example:

10:12:34 [The Ocean] [100% buf] [PLAYING @ 4:23/5:51] Attracting Planet - Oleg Byonic
10:12:35 FTMSI-B closed file for ti/6272A21D; open files:0
10:12:35 FTMSI-B ti/6272A21D download status: AllBlocksDownloaded accessTimeout:True openFiles:0
10:12:35 [zone The Ocean] Track Stopped Due to Error
10:12:35 [zone The Ocean] OnPlayFeedback StoppedEndOfMediaUnnatural

The same signature appears at 6/14 12:12pm, 6/15 4:04pm, and 6/16 11:11am. In every case:

  • The buffer is at 100% - TIDAL content delivery is healthy
  • All audio blocks for the track are fully downloaded
  • The skip is not caused by a network dropout or TIDAL CDN error
What triggers it is the accessTimeout flag in Roon's file cache layer (FTMSI-B). This timeout fires when Roon's internal audio pipeline stops reading from the cached file for too long - meaning the audio consumer on the other end of the Cast stream stalled or slowed down. When nothing is pulling audio, the file handle times out and Roon treats it as a playback error, terminating the track mid-play.

Why Spotify doesn’t skip

Spotify Connect has each device pull its own stream directly from Spotify’s CDN. With Roon casting to a group, the Core is the single sender for all devices. If any member of the Cast group stalls or loses group sync, the shared audio pipeline backs up, nothing reads from the cache, and the timeout fires.

What to try next

Since the issue is tied to the Cast group rather than TIDAL content or your network bandwidth, the most useful thing to test is removing the WiFi members from the group:

  1. Create a new temporary zone with only the two wired-ethernet KEF speakers (no Nest Audios). Play the same TIDAL content and see if skips still occur.
  2. If skips stop with wired-only devices, re-add one Nest Audio at a time to identify which device is losing group sync.
The Nest Audios on WiFi are the likeliest source of group stalls - even at 5GHz, a brief retransmission or roaming handoff between mesh nodes can cause a Cast group member to pause, which is enough to trigger the accessTimeout on the Core side.

Let us know what you find with the wired-only group test and we’ll go from there.

12

I did already try with a KEF-only group, and it skipped. That’s the 7:07pm PDT timestamp a few messages above. All the KEF speakers use ethernet. I’ve run the speaker connection test in the KEF app, they all average ~70 to 80 Mbps.

I have a second KEF-only group that only has two LSX IIs, and I haven’t noticed skipping there yet, though I don’t spend as much time listening to them since I don’t spend as much time in that room.

Note that the Nest Audios are now tied to the 2.4 Ghz band, and show excellent signal strength in the Deco app.

14

Unfortunately I did already try a KEF-only group, that’s the 7:07pm PDT skip from above. I’ve run the KEF app speaker connection test, and all of them average 70 to 80 Mbps.

I have one group that has two LSX IIs (there’s a third LSX II in the bedroom, and the LS50 W2 in the living room, that aren’t part of this group) that hasn’t skipped yet, but I don’t listen to it anywhere near as much as the rest.

Your message got me thinking that maybe the issue is the AdGuard ad blocker running on the Mac mini Roon Core, I’ve disabled it (and stopped all other apps) and will see if that helps.

That box is a 2018, 3.2 GHz 6-Core Intel Core i7, 64 GB RAM box, a little old but I assume it should still be fine if it just serves as a Roon Core, right?

15

Hi @Raul_Acevedo,

Thank you for these extra details and for running that test. This perfectly completes the picture!

To address your points directly:

Why the KEF-only Cast group still skips

You mentioned that you tried a KEF-only group at 7:07pm PDT and it still skipped, despite having strong Ethernet connections. Even with the Nest Audios removed, a “KEF-only group” created in Google Home still relies entirely on the Google Cast protocol.

The logs show that the INVALID_MEDIA_SESSION_ID error is a Cast-layer event, not a device-specific or network bandwidth issue. Over the span of your logs, we see the Cast session reset hundreds of times. Because Roon Core acts as a single synchronized sender to a Cast group, anytime the Cast receiver’s internal state resets, the track drops for everyone. (Note: This is also why Spotify doesn’t skip - each Cast device pulls its own independent stream directly from Spotify’s servers, whereas Roon is broadcasting a unified, synced stream).

Why the two LSX II zone is stable

You noted that your group of two LSX IIs hasn’t skipped yet. Looking at your system diagnostics, this is because that specific pair is grouped using Roon Ready (RAAT) - Roon’s native, highly stable transport protocol - rather than Google Cast. Roon owns the entire session here, so there is no Google Cast session to invalidate.

AdGuard and your Mac mini

To put your mind at ease: your 2018 Mac mini (6-Core i7, 64GB RAM) is an absolute powerhouse and is more than sufficient to serve as your Roon Core!

Additionally, the logs do not implicate AdGuard. The session resets are generated internally by the Cast receiver’s state machine, not by DNS filtering. You can certainly keep testing with AdGuard disabled, but I do not expect it to change the Cast skipping behavior.

The Permanent Solution

Since your KEF speakers support Roon Ready natively, the best way to fix this permanently is to bypass Google Cast entirely for those devices:

  1. Go to Settings → Audio in Roon and enable your KEF speakers under the Roon Ready section (ignore the Chromecast/Google Cast section). They will appear with the Roon Ready.
  2. Group them together using Roon’s native grouping feature

Roon’s native grouping for RAAT devices is fully stable and immune to these Cast resets. Give this a try and let us know how the system performs!

16

The problem is that I want to have synchronized music across the whole house, so using only RAAT means I can’t use the Nest Audios.

Any idea what the INVALID_MEDIA_SESSION_ID error is about?

Note that I shopped around quite a bit to find a small Roon Ready and Chromecast enabled single speaker, and couldn’t find anything. I want both because I use Roon and Spotify. Do you know of any that are roughly the same small form factor as a Nest Audio?

I tried using a Bluesound Pulse Flex 2i with an old Chromecast Audio dongle, but the dongle caused a slight lag, so it was always out of sync with the rest of the speakers. I have an Android phone so I can’t use Airplay.

17

Hello @Raul_Acevedo,

That’s a fair constraint - if Nest Audios are part of the group, Cast has to be the transport for the whole group, and we’re back to the same instability.

On INVALID_MEDIA_SESSION_ID

This error means the Cast receiver lost track of the active playback session. Each Cast device maintains an internal session ID to know “who is currently in charge of my audio.” When that session ID becomes invalid - due to a receiver reboot, a brief network hiccup, or the Cast device’s internal state machine resetting on its own - it stops accepting audio from the sender (Roon Core). Roon then has to tear down and rebuild the entire Cast group session, which causes the skip. Because Roon drives the group as a single synchronized stream, one device dropping its session ID affects everyone in the group simultaneously.

If whole-house sync with the Nest Audios is the priority, Cast is the only common transport available for that mixed group. Since Cast is a third-party protocol, the session reset behavior is outside of Roon’s control. We’d also encourage you to report this to KEF support - since the session resets are originating from the Cast receivers on their speakers, they may be able to investigate whether a firmware update could improve stability on their end.

18

Thank you for the explanation :folded_hands:

I don’t see any of this in my $HOME/Library/Roon/Logs folder on my Mac mini Roon Core, i.e. by running grep -i INVALID_MEDIA_SESSION_ID *. Is there a setting so that I can see more detailed logs myself?

19

Hey @Raul_Acevedo,

On the logs: your grep is empty because you’re looking at the control app’s folder. The Roon Server logs on your Mac mini are under ~/Library/RoonServer/Logs/, or ~/Library/RAATServer/Logs/.

One honest caveat: there are actually two related-but-distinct signatures in this thread, the Cast reset INVALID_MEDIA_SESSION_ID) and a cache stall accessTimeout → StoppedEndOfMediaUnnatural). If you run another wired-only test and it skips, send the timestamp so we can confirm which one is firing before we call this closed.

On a compact speaker that’s both Roon Ready and Chromecast: I’m not aware of a true single-box option in the Nest Audio size class, that overlap barely exists, which matches your search. The closest “both protocols” route is a WiiM Pro/Ultra (Roon Ready + Chromecast + Spotify Connect) feeding a speaker, though that’s a two-box setup rather than an all-in-one.

Lastly, since the Cast resets originate from the receivers on the KEF speakers, it’s worth raising with KEF support too, a firmware update may help on their end. :+1:

20

KEF only Chromecast group skipped twice just now, first at 1:10pm PDT then again 1:12pm PDT.

The StoppedEndOfMediaUnnatural happens first then the INVALID_MEDIA_SESSION_ID, all within the same second.

When filing a bug report with KEF, how much of the logs do I send to them? What is the most useful parrt?

21

Thanks @Raul_Acevedo,

If you haven’t yet, I’d also test whether the leader is the variable. Your stable two-LSX-II zone is stable because it’s RAAT, not Cast, that’s a real confound, so it doesn’t tell us much about the Cast leader.

A cleaner test: in Google Home, make a Cast group where a different wired KEF unit is the leader (Google assigns it, but recreating the group with a different first device often shifts it), then run TIDAL for a while.

On what to send Kef:
Don’t send the whole bundle. The most useful excerpt is the tight window around one skip showing the full sequence in order.

  • The [PLAYING] lines showing 100% buffer right up to the stop (proves the audio was fully delivered to Roon).
  • The accessTimeout:True → Track Stopped Due to Error → StoppedEndOfMediaUnnatural trio with timestamps.
  • The INVALID_MEDIA_SESSION_ID line that follows.
  • The group leader IP (192.168.1.101) and the note that no HTTP audio requests arrived from it in the ~60s before the stall.
Frame it for them as: "Your Cast receiver stopped requesting audio bytes mid-track and then reported an invalid media session; here's the timestamped sequence, is this a known firmware behavior?" Include your KEF model(s) and current firmware version.