Public Board

Auto-skip on a 0.0 segment start freezes transcoded playback

Bug Report Resolved Jellyfin JW TV Public
Submitted Aug 28, 2026 Updated Aug 29, 2026
0
users found this helpful
Vote
Hello, I've hit a reproducible playback bug in JellyWatch TV and narrowed it down to a single cause, so it seemed worth reporting properly rather than just as "it doesn't play". SHORT VERSION When a Jellyfin media segment starts at 0.0, JellyWatch fires its auto-skip on the very first frame of playback. On transcoded content that kills the stream: Jellyfin services a seek by terminating the running ffmpeg and starting a new one at the seek position, so the transcode is torn down while the client is still establishing it. The result is a second or two of picture, then a permanent freeze. The same seek performed a few seconds later works fine, so the transcode restart itself is survivable. The problem is only that the skip is issued during startup. HOW TO REPRODUCE 1. Have an episode whose Intro media segment starts at 0.0. Intro Skipper produces these whenever the detected intro start falls within its EndSnapThreshold of the episode start. 2. The content must require transcoding - e.g. 4K HEVC on a 1080p device. 3. Settings > Skip Segments > Skip intro = "Auto - skip silently". 4. Play the episode. Observed: picture appears, then freezes. The reported playback position is the intro-skip target (in my case exactly 112111 ms) on every attempt, on every episode with a zero-start intro. Expected: playback continues after the skip. WHAT ISOLATES IT Same server, same client, same session - the only variable that predicts success is where the intro segment starts: | Content | Intro start | Transcoded? | Result | | --- | --- | --- | --- | | Show A, 4K | no intro segments | yes | plays | | Show B, 4K | 197.8 s earliest | yes | plays | | Show C, ep. 7, 4K | 6.006 s | yes | plays, skips correctly | | Show C, ep. 1 & 2, 4K | 0.0 s | yes | FREEZES | | Show C, ep. 6, 1080p | 0.0 s | no (direct play) | plays - seeks are free without a transcode | Raising the segment start in the Jellyfin database to 5 s fixes it completely, with no other change anywhere. 2 s is not enough; 5 s, 6 s and 10 s all work: | Segment start | Where the seek landed | Result | | --- | --- | --- | | 2 s | 3 s after ffmpeg start | froze | | 5 s | - | plays | | 6 s | 12 s after ffmpeg start | plays | | 10 s | - | plays | SERVER SIDE IS HEALTHY THROUGHOUT Worth stressing, because it makes this look like a server fault when it isn't: during a failure the transcode runs at roughly 5x realtime, produces zero ffmpeg errors, and every ffmpeg process exits with code 0. Two ffmpeg invocations appear about 3 seconds apart, the second carrying -ss <intro end> and a shifted -start_number - that second one is the skip-triggered restart. Also worth flagging for anyone else debugging this: the client logcat during a failure is full of "PesReader: Unexpected start code prefix", "IDolbyAudioServiceImpl: DeadObjectException" and MediaTek PQ/FRC/hwcomposer errors. All three also appear during completely healthy playback, so they are baseline noise rather than symptoms. They cost me several hours of wrong theories. SUGGESTED FIX Defer the auto-skip until playback is genuinely established - e.g. until the first frames have rendered, or a short fixed delay after playback start - rather than issuing it at position 0. Alternatively, clamp the skip so a segment beginning at 0 doesn't produce a seek before the stream is ready. Either would also make the client robust against zero-start segments from any provider, not just Intro Skipper. ENVIRONMENT - JellyWatch TV 1.0.REV-0320 - Android TV 14, MediaTek SoC, 1080p output; the active codec profile caps HEVC at 1920x1088, so 4K cannot direct-play - Jellyfin 10.11.11, HLS/MPEG-TS transcode via h264_qsv - Skip Segments: all types "Auto - skip silently", Segment detection enabled - Segment providers: Intro Skipper, Chapter Segments Provider 4.0.0.0 Happy to supply logs, the exact ffmpeg command lines, or to test a build if that's useful. Thanks for the app - it's otherwise been solid.
Admin Staff Aug 29, 2026
Thanks for the detailed report, that's excellent debugging work and made the root cause immediately clear. You were right: the auto-skip was firing at STATE_READY, which on transcoded content is too early. The ffmpeg pipeline hasn't stabilised yet, so the seek forces a restart that the client can't survive. The fix defers the skip until the first video frame is actually rendered on the surface, at which point the transcode is stable and the seek goes through cleanly. As a belt-and-suspenders measure, the position ticker is also blocked from triggering any auto-skip before that point. This will be available to test starting from version 0382. Let me know how it goes.