App Name: Fubo TV
Environment: Vega SDK 0.23 · @amazon-devices/react-native-w3cmedia · Shaka Player 4.16.13
We’re hitting an ANR when starting long DVR HLS streams on Vega.
Symptom. For a multi-hour event the media playlist is large — e.g. a ~6h VOD is ~5,400 segments, each with its own EXT-X-KEY and EXT-X-PROGRAM-DATE-TIME. It looks like Shaka’s HLS parser builds all the segment references in a single synchronous loop (HlsParser.createSegments_), which takes ~8s on the device. That blocks JSReactThread long enough to trip the platform ANR watchdog (Thread Monitor). It fires on the initial load and again on each ABR rendition switch (each rendition is its own finite playlist). Data and playback are otherwise fine. I believe it’s purely the parse duration on the JS thread.
Since the native XML parser is DASH-only and doesn’t cover Shaka 4.16 (per the MSE-players / XML-parser docs), the HLS parse runs entirely in JS, so we can’t offload it.
Our workaround. A small local patch to Shaka’s HLS parser: make createSegments_ async and yield to the event loop periodically (every ~500 segments) while it builds segment references. Both callers are already async, so it’s a minimal change. Total parse time is unchanged (~8s), but it no longer blocks — the ANR is gone and playback starts (verified on a release build on-device).
Questions:
- Have you seen this ANR on large HLS manifests with Shaka 4.16 on Vega?
- Is yielding during the parse an acceptable approach, or is there a recommended way to handle large manifests (a supported native HLS parse path, or config to reduce the parse cost)?
- Any guidance to reduce the ~8s parse itself? Time-to-first-frame is still slow on these long playlists even with the ANR fixed.