Indefinite Playback Stall after seeking backwards beyond buffered media range

Vega Open Beta Bug Reports
1

:warning: Before you continue

Before submitting a bug report, please review our troubleshooting documentation at Troubleshoot Issues | Vega Troubleshooting

If you still want to file a bug report, please make sure to fill in all the details below and provide the necessary information.

NOTE: PLEASE ONLY REPORT A SINGLE BUG USING THIS TEMPLATE.
If you’re experiencing multiple issues, please file a separate report for each.

:backhand_index_pointing_right: Bug Description

1. Summary

After building up buffered media for LIVE content and performing a backward seek beyond back buffer, the Video Player gets stuck in buffering state indefinitely.

App Name:
App Link on Amazon Appstore (found through Developer Console → Actions column in App List → View on Amazon.com):

Bug Severity
Select one that applies

  • Impacts operation of app
  • Blocks current development
  • Improvement suggestion
  • Issue with documentation (If selected, please share the doc link and describe the issue)
  • Other

2. Steps to Reproduce

  1. Launch Live content
  2. Let it play for 3 minutes or so to build up the buffer
  3. Press the rewind button on the remote control.
  4. Let the player marker reach the beginning of the buffer.
  5. The issue will happen after few seconds.

3. Observed Behavior

Explain what actually happened, noting any discrepancies or malfunctions.

After seeking backwards to unbuffered range, and HLS.js appends media to media source. Player reports that it's playing, however the player gets stuck indefinitely.

4. Expected Behavior

Describe what you expected the SDK to do under normal operation.

We expect playback to resume after seeking and appending media to MediaSource.

4.a Possible Root Cause & Temporary Workaround

Fill out anything you have tried. If you don’t know, N/A is acceptable

Nudging the playhead position forward after getting stuck resolves the stall.

5. Logs or crash report

(Please make sure to provide relevant logs as attachment)

For crash issues, please refer this guide for faster troubleshooting: Detect Where the App Crash Originates | Design and Develop Vega Apps

Device Logs - 192.168.132.102_5555.log (3.1 MB)

6. Environment

Please fill out the fields related to your bug below:

  • SDK Version: 0.22.5850

  • App State: Foreground

  • OS Information: Please ssh into the device via vega exec vda shell (or kepler exec vda shell for v0.21 and earlier) and copy the output from cat /etc/os-release into the answer section below. Note, if you don’t have a simulator running or device attached, the command will respond with vda: no devices/emulators found

    NAME="OS"
OE_VERSION="4.0.0"
OS_MAJOR_VERSION="1"
OS_MINOR_VERSION="1"
RELEASE_ID="14"
OS_VERSION="1.1"
BRANCH_CODE="TV Ship day60"
BUILD_DESC="OS 1.1 (TV Ship day60/102)"
BUILD_FINGERPRINT="4.0.253712.0(3072cab629675a74)/102N:user/release-keys"
BUILD_VARIANT="user"
BUILD_TAGS="release-keys"
BUILD_DATE="Fri Mar 20 21:10:28 UTC 2026"
BUILD_TIMESTAMP="1774041028"
VERSION_NUMBER="1401010010220"

7. Example Code Snippet / Screenshots / Screengrabs

Include any relevant code or component setup in React Native that can help reproduce the bug.

N/A

:backhand_index_pointing_right: Playback Issues

If this is a playback issue, please provide your content URL, any pre-conditions (like geo-location), and let us know if it’s x86 or arm7.


N/A

Please share the following details in addition:_

  • Player SDK: HLS.js
  • Player SDK Version: 1.6.10
    • Audio Codecs: [AAC]
    • Video Codecs: [h.264]
    • Manifest Types: [m3u8]

Q: If applicable, please provide your media/content url
If this is created dynamically, tokenized, etc please provide a way for us to access it

N/A

Q: Are there any special headers required to reproduce the issue you are facing?

[N/A

Additionally please provide the following if possible
Provide Screenshots / Screengrabs / Logs. Please include as much information as you can that will help debug.

N/A

:backhand_index_pointing_right: Additional Context

Any Additional Context you would like to provide?
Add any other relevant information, such as recent updates to the SDK, dependencies, or device OS that may affect the bug.

We will provide a build to Amazon via external channel.
4

Hi @Kyle_Seager ,

Thank you for the detailed bug report on the indefinite playback stall after seeking backwards beyond the buffered range.

What’s happening: We’ve analyzed the device logs. After your seek to 3622s completes and playback begins, HLS.js removes the old forward buffer ([3667+]) via SourceBuffer.remove(). At this point, the native MSE pipeline’s internal read-head pointers were still referencing samples in that old region (from before the seek). The removal triggers an internal “Pending Seeking” to the now-deleted timestamps (3667.729s for video, 3667.665s for audio), which corrupts the pipeline state.

The result: the GStreamer decoder starves (sampleQueueDepth stuck at 98 < 400 threshold), get_media_time reports the actual time going backwards vs. the last reported time, and the pipeline clamps - so currentTime freezes at 3625.655 permanently despite 24+ seconds of data being buffered ahead. This is a issue in the TrackBufferImpl read-head management during SourceBuffer.remove() after a seek.

In the meantime, your workaround of nudging the playhead forward is correct. You can also automate it with a stall-detection timer after seeked events.

Our team is investigating this issue and will provide an update as soon as we have more information.

Thanks for helping us improve the Vega platform.

Warm regards,
Aishwarya