HLS resume/seek playback in Emby 4.9.5.0 causes bufferSeekOverHole, subtitle discontinuity, A/V/subtitle desyn

[Gigity 0]

I am reporting a reproducible HLS playback issue in Emby Server 4.9.5.0.

The issue happens when playing a video through Emby Web using HLS, especially when resuming playback from a saved position in the middle of the video, or after manually seeking to another position. If I start the same video from the beginning, playback usually works normally and the subtitles stay in sync. The problem appears only after resume/seek playback in the HLS remux/transcode path.

The most visible symptom is that hls.js reports repeated non-fatal media errors such as:

 

HLS Error: Type: mediaError Details: bufferSeekOverHole Fatal: false Reason: fragment loaded with buffer holes, seeking from 887.327815 to 888.6159769999999

After these HLS errors appear, playback no longer behaves as if the video, audio, and subtitle clocks are aligned. Subtitles may become discontinuous or jump in timing, and they no longer match the spoken audio or video scene. In my tests, the subtitles often become ahead of the video by around 1.6 seconds, but the offset is not always exactly the same. Sometimes the video/audio timeline also appears to shift after the buffer hole recovery, which makes the subtitle timing incorrect even though the subtitle file itself is valid.

This does not look like a general subtitle file problem. The same media can play correctly from the beginning. The desync is triggered by HLS resume/seek behavior and usually appears after hls.js reports bufferSeekOverHole.

In some tests, seeking also caused playback to fail completely with the client message:

 

No compatible streams are currently available. Please try again later or contact your system administrator for details.

From the server-side ffmpeg logs, the affected playback sessions use segmented HLS output with arguments such as:

 

-copyts -start_at_zero -ss <resume position> -segment_time 00:00:06.000 -segment_time_delta -<resume offset> -segment_start_number <non-zero segment index> -segment_format mpegts

The issue seems related to the generated HLS timeline after resume/seek, because hls.js detects buffer holes in the loaded fragments and performs an internal seek over the hole. After that recovery seek, subtitle timing is no longer reliable.

Expected behavior:

Resume playback and manual seeking should continue normally without HLS buffer holes, without subtitle timing discontinuity, and without A/V/subtitle desync. Starting playback from a saved position should behave the same as starting from the beginning and then seeking naturally.

Actual behavior:

When resuming or seeking during HLS playback, hls.js may report bufferSeekOverHole. After that, subtitles can become early or otherwise misaligned with the video/audio. In some cases playback fails with “No compatible streams”.

Environment:

 

Emby Server: 4.9.5.0 Client: Emby Web Browser: Microsoft Edge / Chromium-based browser Playback: HLS via hls.js Container: MKV Video: HEVC Main 10 Audio: OPUS source, remux/transcode path may convert audio Subtitles: ASS subtitles, including internal/external ASS tracks Trigger: resume from saved position or manual seek Starting from 0:00: usually works correctly

I have attached anonymized logs from the affected playback attempts:

 

embyserver.anonymized.txt ffmpeg-remux-resume-1.anonymized.txt ffmpeg-remux-resume-2.anonymized.txt

The logs preserve the relevant HLS/ffmpeg details such as the ffmpeg command line, segment start number, segment timing options, HLS segment responses, Content-Length, and SegmentComplete entries. Private paths, IP addresses, hostnames, tokens, session IDs, media titles, and user identifiers have been anonymized.

embyserver.anonymized.txt ffmpeg-remux-resume-1.anonymized.txt ffmpeg-remux-resume-2.anonymized.txt