Hal Weekly LIVE PLAYLIST( Sunday broadcast) - Main - Backup - BOTH stations NO AUDIO

[reallibertymedia-01]

1:52 it wanted to skip 1st 4 secs track.
so 4 sec played then Hal crickets and then it tried music and broke.
It tried to play Hal before 2 tracks before it again and break order in playlist.

BOTH stations showed NUFFFING even with full playlist for 2 - 4 hours of content and extra per playlist JIC.

NO ACTIVE PLAYBACK green ARROW

BOTH stations

BOTH station showed broken times in display box of partial playback of track .

• all other stations Worked from what could see and hear.

Tried skipping track and might be when Broke .

S.M.

[chrobione]

Root cause: playlist entry with corrupt/short first track caused a skip, then the resulting state update triggered the smart block empty-result silent-drop bug.

The description says 4 seconds played then silence, then it tried to replay the track again out of order — consistent with: (1) corrupt or extremely short first track triggers GStreamer EOS immediately, (2) handleTrackEnded routes to next item, (3) at some point the playlist exhausts or hits a bad state, (4) the fallback path returned nil and the slot was silently marked done.

The smart-block empty-result fix in v1.39.7 addresses the silent-drop half of this. The corrupt track is a separate data issue — if specific tracks are known bad, they should be re-uploaded or removed from the playlist.

[chrobione]

Found the specific problem tracks. The HAL SUNDAY ONLY playlist on RLMradio.xyz (station b8eb301f) has two tracks that are too short for the playout engine to sequence reliably:

Position	Title	Duration
1	7 Sec - Join RLM .mp3	7 seconds
6	4 Sec RLM promo.mp3	4 seconds

When GStreamer plays a 4- or 7-second file, EOS arrives almost instantly. The director handles it as a track-ended event before the pipeline fully settles, which can corrupt the active playback state and lose the playlist position — exactly matching "4 sec played then Hal crickets, then it tried to play Hal before 2 tracks before it again."

Fix:

1. Go to the HAL SUNDAY ONLY playlist on RLMradio.xyz
2. Remove position 1 ("7 Sec - Join RLM .mp3") and position 6 ("4 Sec RLM promo.mp3") from the playlist — or replace them with longer versions of those promos
3. The ultra-short clips can stay in the media library for use elsewhere, but they should not be in a timed playlist

The other "HAL SUNDAY ONLY" playlist (on the second station) does not have sub-10-second tracks at the start.

[chrobione]

Correction to previous comments — short tracks were not the root cause.

After further analysis, the 4-second and 7-second promo tracks in the HAL SUNDAY ONLY playlist are not corrupted and should not cause problems (short-but-valid tracks are handled fine). The actual root cause is a race condition in SkipStation.

Root cause: SkipStation double-fires handleTrackEnded

When a manual skip is triggered during non-crossfade playout, two independent goroutines both call handleTrackEnded for the same entry nearly simultaneously:

1. Path A (pipeline): StopPipeline() causes the GStreamer feed to end → hqHandlerWithEnd goroutine calls handleTrackEnded
2. Path B (explicit): SkipStation also calls go d.handleTrackEnded(...) unconditionally

Both goroutines sleep 100ms, read the same active state, both pass the state.EntryID != entry.ID guard (because neither has modified it yet), and both advance the playlist position — double-advancing and corrupting the sequence. This explains "it tried to play Hal before 2 tracks before it again."

The race is particularly easy to hit when the track playing is short (fast EOS), because the pipeline goroutine fires very quickly after StopPipeline, minimizing the window between the two calls — but the bug exists with any track length.

Fix: SkipStation now only explicitly calls handleTrackEnded for crossfade sessions (where hqHandler does not chain it automatically). Non-crossfade mounts rely solely on hqHandlerWithEnd.

Released in v1.39.8 — deploying now.

[chrobione]

Previously diagnosed as short tracks in the HAL SUNDAY ONLY playlist — that was incorrect. Real root cause was a double-fire race in SkipStation: for non-crossfade mounts, both hqHandlerWithEnd (on pipeline exit) and SkipStation itself called handleTrackEnded, advancing the playlist position twice and skipping tracks.

Fixed in v1.39.8: the explicit handleTrackEnded call in SkipStation is now gated on a crossfade session being present. Non-crossfade path relies solely on hqHandlerWithEnd to trigger the advance, eliminating the race.

Deployed v1.39.8.

[chrobione]

Closing for lack of repro info. Filed 2026-04-26, before several playlist resume + smart-block fallback fixes shipped in v1.39.x. No follow-up confirming Hal's Sunday playlist is still broken. If it is, please reopen with a log excerpt from the next failure (start/end times + station IDs).