Repository navigation
Native remote HLS (.remoteBypass) leaves clock.bufferedPosition at zero during playback #935
Description
Observed on 7.51.0
On a tvOS arm64 simulator, native remote HLS (videoRoute == .remoteBypass) plays and seeks, but clock.bufferedPosition stays 0. This is distinct from #835, which concerned paused native loopback playback.
An integration test loads a locally served synthetic H.264 fMP4 HLS VOD through the production AetherEngine API, verifies automatic .remoteBypass, starts playback, seeks to 8 seconds, and waits for bufferedPosition > currentTime.
Observed:
- Seek target 8.0, landing 8.000474041 seconds.
- Buffer-ahead expectation times out.
bufferedPosition == 0.0atcurrentTime == 20.215616416.- The test retains a strict expected failure for the two buffer assertions; this is not a successful buffer check.
Pinned release: 7.51.0, commit a877941bd3402d5f531edad0cbe4c9b33eefa856. No engine modifications. Physical-device reproduction has not been performed.
Fixture recipe
Starting with a synthetic H.264 test-pattern MP4, generate fMP4 HLS:
ffmpeg -hide_banner -v error -i fixture.mp4 -t 20 -an -c:v copy \
-f hls -hls_segment_type fmp4 -hls_time 2 -hls_playlist_type vod \
-hls_fmp4_init_filename init.mp4 -hls_segment_filename 'seg%02d.m4s' native-hls.m3u8Serve the playlist and segments over local HTTP, load the playlist through the normal automatic route, verify .remoteBypass, then observe clock.currentTime and clock.bufferedPosition during playback and after seeking. Expected: publish the actual contiguous AVPlayer buffered frontier rather than leaving it at zero.
Static comparison with 7.52.0
7.52.0 has not been runtime-tested here. Read-only comparison indicates the same publication gap:
loadRemoteHLSsinks wire current/rendered times but do not publish bufferedPosition.refreshNativeBufferedPositiondepends onnativeVideoSession; the no-argument refresh exits if it is absent. Remote bypass creates a NativeAVPlayerHost without the loopback nativeVideoSession.
Could the remote-bypass route publish the actual AVPlayer loaded-range frontier, including while paused? We are keeping upstream unchanged rather than duplicating engine buffering state in the app.
Activity
quint-aether commentedon Oct 30, 2026
This is related to #835, which was closed. That issue covered paused native loopback playback, while this one is about the remote HLS bypass route. On
main,docs/api.mddocumentsclock.bufferedPositionas "never belowcurrentTime". A value of 0 atcurrentTime == 20.2does not match that contract. The two code paths named in the report also look the same onmainas in 7.52.0. The report has what is needed to reproduce it, so it is ready for review.Automated triage by Quint (Claude). A maintainer reads every issue and will follow up.
fix(native): guard the remote-HLS buffer refresh by route (#935)
Merge fix/935-remote-hls-buffered-position: publish the remote-HLS bu…
superuser404notfound commentedon Oct 30, 2026
Thanks for the precise report and the fixture recipe, it reproduced on the first run.
Fixed on
mainin 721254e (f3f82fd + a8b638c), not in a release yet.Cause: the shared refresh returned early without a loopback
nativeVideoSession, and the remote bypass never has one, soclock.bufferedPositionkept its reset value of 0 for the whole session.Fix:
.remoteBypassnow publishes the end of AVPlayer's ownloadedTimeRangesrange that is contiguous with the playhead (or with the pending seek target while a seek is in flight), clamped to never trailcurrentTime. It refreshes on every rendered-time tick and on every change of the loaded ranges, which AVFoundation keeps reporting while paused, so the value also moves in a paused session. Disconnected islands are not counted.Verification with
aetherctl play --native-hlsagainst a 40 s fMP4 HLS VOD built with the recipe above, served over local HTTP:buf=0.00buf=40.00buf=0.00buf=40.00buf=0.00buf=40.00Loopback serves the whole file at once, so this run shows the value arriving, not its growth over a slow link; a throttled origin or the simulator test with the expected failure removed would cover that part. Keeping the issue open until it is confirmed on your side once a release carries it.
fix(native): publish the remote-HLS buffered frontier (superuser404no…