Hey @c_h_1,
Thanks for sharing a more specific timestamp! From logs, we can see:
03:18:35 — A “Playing 1 Items” action is triggered for Feel It (Protoje) while To and Fro (Jean-Luc Ponty) is still playing at 2:10/4:21. This is the playlist add landing in the queue.
03:18:36 — Critical log line:
[Living Room] [zoneplayer] BufferingTrack != PlayingTrack during _Queue. Refusing to queue
Roon detected a mismatch between what was buffering and what was playing, and
refused to pre-queue the next track at that moment.
03:20:33 — To and Fro ends naturally (4:21 duration confirmed). The Sonos reports STOPPED and Roon interprets it as device stopped or paused by user, ending stream — even though it was a natural track end. This isn’t the issue.
03:20:34 — Roon immediately starts Feel It (Protoje) fresh — it was not pre-buffered going into this transition, because the queue operation was refused at 03:18:36. It has to re-fetch the TIDAL stream from scratch.
03:21:29 — While Feel It is playing at 0:51/3:33, a Seek 0 command is issued, restarting the track from the beginning. This is the “skip” you observed — but it’s actually a seek-to-zero, not a skip forward.
03:21:31 — A notable warning appears:
startpos is out of range, returning file headers only. start, pos, sum, end, offset: 0, 41611744, 986159, 576000
This indicates the Sonos player tried to seek into the file at a position that was out of range relative to what was buffered/served.
When you cleared the 6-song queue, added 1 song, then added the Tidal playlist, Roon’s internal transport state had a BufferingTrack != PlayingTrack mismatch. This prevented the next track from being properly pre-staged. When the transition happened, combined with a client reconnect (the remoting sessions dropped and reconnected multiple times at 03:10, 03:20, 03:21), a spurious Seek 0 was sent to the zone — restarting Feel It rather than skipping it.
The repeated incomplete receive errors on the remoting connection from 192.168.68.105 (your control device) are also notable — the app was losing and re-establishing its connection to Roon Server multiple times during this window, which likely contributed to the spurious seek command.
Let’s see if we can better Isolate the “BufferingTrack != PlayingTrack” condition. This is the earliest indicator that something went wrong. Try to reproduce the issue by:
- Playing a track, clearing the queue mid-song, then adding a single track + a Tidal playlist in quick succession (within a few seconds of each other)
- Check if the timing between adding the single track and adding the playlist matters — does a longer gap prevent the mismatch?
With that, what device is at 192.168.68.105? Is it on WiFi? Try reproducing on a wired connection or a different device.
- Does the issue occur if the control device stays stably connected (no screen sleep/backgrounding during playback)?
Lastly, see if you can reproduce without the Tidal playlist step. Does the issue still happen if you skip step 4 (adding the Tidal playlist)? The “Playing 1 Items” log entry at 03:18:35 suggests the playlist add triggered the queue rebuild that caused the mismatch. Confirming the playlist addition is necessary narrows the potential bug significantly.
Thank you! 
