Seeking video rapidly causes playback to stall indefinitely on Firefox, Chrome, Safari

[Andrews54757]

Environment

Firefox Developer Edition 121.0b1 (Arm 64). M1 Macbook Pro.

Also reproduced using Chrome and Safari

Steps to reproduce

1. Go to the reference player
2. Press Play
3. Click and drag seeker close to the end of the video
4. Wait for the image to change
5. Still holding the mouse down, drag seeker to start of video (not too fast, not too slow).
6. Video will stall indefinitely. (may require multiple tries to get it to happen, but it is pretty consistent for me)
   

Observed behavior

Video will be buffering indefinitely.

Expected behavior

Player shouldn't stall after seeking.

[Andrews54757]

Was able to reproduce using Safari.

[LennartPaduch]

Steps to reproduce

1. Drag seek bar backward across multiple segments
2. Observe player sometimes becoming unresponsive to seeks

Note: While this bug can occur when rapidly seeking from any position (middle, beginning, etc.), starting from near the end of the video provides the longest "runway" for rapid backward seeks, maximizing the chances of triggering the race condition. The reproduction code below uses this approach.

Programmatic Reproduction

This bug can be reproduced pretty consistently with a simplified test. Since it's timing-sensitive, you might need to tweak seekIntervalMs and/or jumpSize depending on your machine.

Code to reproduce the bug

(function () {
    var url = // manifest url

    var player = dashjs.MediaPlayer().create();
    player.updateSettings({
        debug: {
            logLevel: dashjs.Debug.LOG_LEVEL_DEBUG
        }
    });
    player.initialize(document.querySelector("#videoPlayer"), url, true);

    const videoElement = document.querySelector('#videoPlayer');
    console.error("Player object:", player);

    const delay = (ms) => new Promise(resolve => setTimeout(resolve, ms));

    let isTestRunning = false; // To ensure the test runs once

    // --- Test Configuration ---
    const totalSeeks = 999; // Number of rapid backward seeks
    const seekIntervalMs = 70; // Milliseconds between each direct currentTime update
    let segmentDuration = 3; // Fallback value, will be updated
    const endPos = 0;

    let currentPos; // Will store the current position during rapid seeks
    let seeksDoneCount = 0; // Tracks how many rapid seeks have been performed
    let rapidSeekTimerId = null; // Stores the setTimeout ID

    // --- The Core Rapid Seek Test Function ---
    const startRapidBackwardSeekTest = async () => {
        if (isTestRunning) return; // Prevent multiple runs
        isTestRunning = true;

        console.log('--- Starting Precise Rapid Backward Seek Test ---');

        // 1. Wait for duration and segmentDuration
        let duration = player.duration();
        while (isNaN(duration) || duration === 0) {
            await delay(100);
            duration = player.duration();
        }

        try {
            const currentVideoRepresentation = player.getCurrentRepresentationForType(dashjs.Constants.VIDEO);
            if (currentVideoRepresentation && !isNaN(currentVideoRepresentation.segmentDuration)) {
                segmentDuration = currentVideoRepresentation.segmentDuration;
                console.log(`Discovered video segment duration: ${segmentDuration.toFixed(2)}s`);
            } else {
                console.warn('Could not get video segment duration. Using default 3s.');
            }
        } catch (e) {
            console.error('Error getting segment duration:', e);
        }
        console.log(`Video duration: ${duration.toFixed(2)}s`);
        await delay(500); // Small delay to let initial playback settle slightly

        // 2. Initial jump to near the end (simulates user clicking/dragging first)
        currentPos = duration * 0.9; // Start at 90%
        console.log(`Phase 1: Initial jump to ${currentPos.toFixed(2)}s`);
        videoElement.currentTime = currentPos; // Direct manipulation as per bug description

        // Wait a moment for this initial jump to trigger its `seeking` events and clear buffer
        await delay(500);
        console.log('Phase 1: Initial jump processed. Starting rapid backward drag simulation.');

        // 3. Start the rapid backward seeking loop
        seeksDoneCount = 0;

        const doRapidSeek = () => {
            // Check if we've reached target or max seeks
            if (seeksDoneCount >= totalSeeks || currentPos <= endPos) {
                console.log('Phase 2: Completed rapid backward seeks. Targets reached near start.');
                clearInterval(rapidSeekTimerId); // Stop the loop
                rapidSeekTimerId = null;


                return; // Exit doRapidSeek
            }

            // Calculate next position: jump backward by 'segmentDuration * x
            // This creates the conditions that triggers the bug
            const jumpSize = segmentDuration * 1.25;
            currentPos = Math.max(endPos, currentPos - jumpSize); // Ensure we don't go below endPos

            console.log(`[TEST] Seek ${seeksDoneCount + 1}/${totalSeeks}: current: ${videoElement.currentTime.toFixed(2)}s -> target: ${currentPos.toFixed(2)}s`);
            videoElement.currentTime = currentPos; // Direct manipulation (simulates dragging)
            seeksDoneCount++;

            // Schedule the next rapid seek
            rapidSeekTimerId = setTimeout(doRapidSeek, seekIntervalMs);
        };

        // Start the rapid seek loop
        doRapidSeek();
    };

    // --- Trigger the test after manifest loaded and player is ready ---
    player.on(dashjs.MediaPlayer.events.MANIFEST_LOADED, () => {
        setTimeout(startRapidBackwardSeekTest, 500); // Give player extra time to init
    });

})();

Findings

The PlaybackController gets stuck in an internal seek state, causing playback to stall indefinitely. Here's what happens:

1. Rapid _onPlaybackSeeking events: When users drag the seek bar, the browser rapidly fires native seeking events (each drag position update directly sets videoElement.currentTime).
2. adjustSeekTarget triggers an "internal seek": During this chaos, usually right after a segment is appended, the BufferController's _adjustSeekTarget might method kick in to snap the currentTime to a buffered range.

// In BufferController.js, within _adjustSeekTarget()
// ...
playbackController.seek(range.start, false, true); // <-- The 'internal=true' parameter is key here.
// ...

3. _onPlaybackSeeking gets trapped and skips crucial state resets (The Deadlock Origin): Once internalSeek is true, subsequent calls to PlaybackController._onPlaybackSeeking() (triggered by the continued rapid videoElement.currentTime changes) encounter an early exit condition:

// In PlaybackController.js, within _onPlaybackSeeking()
if (internalSeek) {
    return; // Exits immediately if internalSeek is true
}

This is meant to ignore seeking events during internal adjustments. I got curious about why this flag existed, so I dug into the commit history. This flag was first added in commit by Nicolas ANGOT in June 2018, where its original purpose was to unregister the native seeking listener to prevent interference with downloading requests during internal seeks. It was later modified in commit by Bertrand Berthelot in March 2021 to its current flag-based approach, with the stated intent: "to simply ignore next 'seeking' event after internal seek, so that concurrent user seeks can be considered (without waiting for 'seeked' event)".

Here's the problem: that early return blocks critical state updates that would normally help the player recover after a seek.

4. internalSeek remains true indefinitely (the deadlock):
   The internalSeek flag is primarily reset to false in PlaybackController under only a few conditions:

   • _onPlaybackPlaying(): When the native video element emits a playing event.
   • _onPlaybackSeeked(): When the native video element emits a seeked event.
   • _initializeForFirstStream(): During initial player setup.
   • When an external playbackController.seek() is called (where its internal parameter is false).

   But here's the thing: during rapid seeking, neither _onPlaybackPlaying() nor _onPlaybackSeeked() fire reliably.
   So internalSeek stays true forever. The player is now completely stuck. I think it thinks it's still doing an internal seek and ignores everything else. No more seeks, no segment fetching, no playback. Game over.

5. Buffer Invalidation Race Condition:
   What I've seen in debugging is that BufferController tries to snap to a buffered range, but the rapid currentTime changes cause that range to get wiped out right after _adjustSeekTarget starts its internal seek. This creates a critical race condition: by the time the internal seek attempts to complete, its target buffer range has been invalidated, preventing the browser from ever firing the seeked event that would clear the internalSeek flag.

[ShikiSeiren]

I tried both methods to reproduce the bug.
The original way no longer works, as the behaviour of the player has been changed; it will always only start seeking when the mouse button is released.
I managed to reproduce it using Lennart's test code. As far as I can tell, the flag is only ever supposed to skip the onPlaybackSeeking function once after an internal seek. I made sure the flag is reset upon reading it in the function, after which the stalling issue could no longer be reproduced.