Hi Benjamin
I asked Claude to review the log file for the period during which I encountered the problem (I’m essentially non-technical, so need all the help I can get 
) and I’ve included that below.
To answer your questions, the LSX II LT’s are at latest firmware level (2.1.86) and nothing has been changed on the network side. I had been using Airplay without any problem, but was told Chromecast supported higher bit-rates and so switched to that recently. As far as I’m aware, when the error occurs there’s no change in format, nor any warning; playback simply stops and a few seconds later, the next track begins. Hope the attached file might be of some help… please advise if I should send the original Roon log as well…
Claude response:
I found the exact failure signature three times in this log, and there’s a clear pattern behind it — plus a specific culprit visible in the data that’s worth checking.
What happens at each failure (concrete example, 08/17 07:49:19)
“Freddie Freeloader” (a 24-bit/48kHz TIDAL FLAC) was playing in the Study zone at 4:58 into a 7:17 track, fully buffered (Roon’s log shows [100% buf] — the whole file was already sitting in Roon’s cache, so this wasn’t Roon struggling to pull data from Tidal). At that exact second the log shows:
Warn: [zone Study - LSX II LT Chromecast] Track Stopped Due to Error
Info: [zone Study - LSX II LT Chromecast] OnPlayFeedback StoppedEndOfMediaUnnatural
…
Error: [cast/client] Media error: {“type”:“INVALID_REQUEST”,“reason”:“INVALID_MEDIA_SESSION_ID”…}
Then Roon immediately advances to the next track (“Blue In Green”). This is the same signature I found documented in Roon’s own support forum for this exact combination of gear: the KEF’s Chromecast receiver unilaterally ends the media session (StoppedEndOfMediaUnnatural), and when Roon’s server then tries to send it a follow-up command, the KEF rejects it because it no longer recognizes that session ID. Roon isn’t choosing to stop the track — the speaker’s Cast receiver is dropping the session, and Roon is just reacting by moving on. This happens again at 12:02:44 and 12:49:32 the same day, always with the identical StoppedEndOfMediaUnnatural → INVALID_MEDIA_SESSION_ID pairing.
What’s triggering it in your case specifically
This is where your log gets useful beyond the generic “Chromecast is less robust than RAAT” explanation. Looking at Roon’s own internal [stats] lines (which report how much of RoonServer’s runtime is spent frozen in garbage collection), there’s a clear correlation: in quiet periods the GC pause is a calm 0.4–2.3% of each 15-second window. But in the run-up to and during each of the three dropouts, that spikes hard — 7–10% around the first event, a 3-second GC pause consuming over 20% of one window right at the second event, and 4–9% around the third. In other words, at the moment each track cut out, the RoonServer process itself was periodically frozen doing garbage collection for a meaningful chunk of every second.
That matters because your Roon Ready zones use RAAT, a protocol Roon fully controls with generous, forgiving buffering on the endpoint side — a brief server stall doesn’t bother it. The KEF, being a generic Chromecast device, is on Google’s Cast protocol instead, which expects a steadier stream of session/keep-alive traffic from the sender. If RoonServer is stalled for a second or more doing GC, it can miss that cadence, and the KEF’s own Cast receiver concludes the sender is gone and tears down the session — exactly what the log shows.
Two more details support this: the machine identifies itself as a base “Nucleus” (not Nucleus+), which historically ships with more limited RAM, and around the second incident there’s a burst of expensive internal [music/profilestats] computations (2.5–3.6 seconds each, repeating every few minutes between 11:28 and 12:09) — these are typically triggered by a Roon remote app sitting on the Overview/Discover screen, and they’re a plausible driver of that memory pressure.
