Headless JS Playback — SIGABRT in player service (libplayerserviceimpl_service.so) after sustained looping of a short video

Vega Open Beta Bug Reports
1

Bug report (English, copy-paste)

Title: Headless JS Playback — SIGABRT in player service (libplayerserviceimpl_service.so) after sustained looping of a short
video

Environment

  • Vega SDK: 0.22.6759
  • Device: Fire TV Stick 4K Select (armv7), OS callie-user OS 1.1
  • Build: release vpkg (armv7)
  • Packages: @amazon-devices/react-native-w3cmedia ~2.1.80, @amazon-devices/kepler-player-server 2.2.9,
    @amazon-devices/kepler-player-client 2.2.9, @amazon-devices/headless-task-manager 1.2.4

Setup
Headless JS Playback implemented following the official guide. A service component hosts the player via kepler-player-server
(PlayerServerFactory + IPlayerServerHandler), driving the W3C headless VideoPlayer. The interactive component is a client
(kepler-player-client): getOrMakeClient(serviceId) → load(mediaInfo, {startPosition:0, autoPlay:true}, sessionId) → on
KeplerVideoSurfaceView.onSurfaceViewCreated → setVideoView(handle, sessionId) → play(sessionId).
Source: a single short MP4 (~6 s), served from a local file (downloaded once via expo-file-system). In the service:
videoPlayer.loop = true; videoPlayer.muted = true; videoPlayer.autoplay = true. Single session, no track switching, no DRM.

Use case
Digital signage: one short video looping continuously, unattended, for hours.

Steps to reproduce

  1. Start headless playback of a short MP4 (~6 s) with loop = true.
  2. Leave it looping continuously (hundreds of loop iterations).
  3. After ~1 hour the service process aborts (SIGABRT) and the app closes to Home.

Expected
Continuous, stable looping playback over long periods.

Actual

  • On every loop boundary the pipeline fully re-buffers: logs show Pipeline is buffering v[..%] a[..%], MediaPlayerMPBImpl::seek
    (~300 ms), State change from ENDED to PAUSED. This causes a visible glitch each loop even from a local file.
  • After ~1 h of sustained looping the player service crashes with SIGABRT.

Crash report (ACR)

  • File: crash_…_JSThread_55_65.acr
  • CrashReason: SIGABRT (libc abort)
  • Modules in the faulting stack: libplayerserviceimpl_service.so, libplayerserviceimpl_client.so, kepler-player-server /
    kepler-player-client (hermes bundles), service.hermes.bundle (our PlayerService), libhermes-0.12.0.
  • (ACR file attached.)

What we tried / additional data

  • Local-file caching of the media (vs network streaming) greatly extended time-to-crash (from ~6 min when streaming to ~1 h
    cached), which points to the per-loop re-buffer/seek as a contributing factor.
  • Running the same VideoPlayer (w3cmedia) in-UI, without the kepler-player-server service layer, did not reproduce this SIGABRT
    in the same scenario — suggesting the abort originates in the player-server/service layer under sustained looping.

Questions

  1. What is the recommended lifecycle for infinite looping in headless playback — videoPlayer.loop = true, vs handling ended with
    a controlled reload, vs periodic unloadSync/re-init?
  2. Is the per-loop full re-buffer (ENDED → seek → buffering) expected for a local short file, or is there a gapless/seamless loop
    mechanism?
  3. Is this SIGABRT in the player service under prolonged looping a known issue, and is a fix planned / available in a newer SDK?

Attachments: ACR file, relevant device logs (loggingctl).

4

Hi @Anthony_Ogbemudia,

Welcome to Amazon Developer Community!!

Thank you for the detailed bug report.

  1. Recommended looping approach: Rather than videoPlayer.loop = true, we recommend handling the ended event with a controlled deinitialize/reinitialize cycle. This ensures the media pipeline is cleanly reset each iteration, preventing resource accumulation:
videoPlayer.addEventListener(‘ended’, async () => {
await videoPlayer.deinitializeSync(1000);
videoPlayer = new VideoPlayer();
await videoPlayer.initialize();
// reload and play
});

  1. Per-loop re-buffering: The full re-buffer on each loop for a local file is not expected behavior. The controlled reload approach above should provide more predictable results for your use case.

  2. SIGABRT crash: Please share the ACR file and device logs so we can investigate further.

Resources:

Best regards,
Aishwarya

5

Hi @Anthony_Ogbemudia,

Thank you for your patience.

To investigate the SIGABRT crash further, could you please share:

ACR file — the crash_…_JSThread_55_65.acr file referenced in your report
Device logs — captured via loggingctl around the time of the crash
You can attach them directly to this thread or upload to a shared location and provide the link.

Once we have these, we’ll be able to dig into the faulting stack and identify the root cause.

Best regards,
Aishwarya