3.11.5

Fixed

Long delay to first subtitle cue when a track is activated mid-playback on a slow/remote source (#52)

Calling selectSubtitleTrack(index:) mid-playback without pausing on a large/remote (high-latency) source showed the first on-screen cue tens of seconds late (~25-35s observed) instead of the ~1-2s the API promises.

Root cause. The side demuxer captured the playhead (startAt) before demuxer.open and the duration*0.5 cue-table prewarm seek. On a high-latency source those steps cost several seconds of wall-clock, during which unpaused playback keeps advancing. The reader then seeked to the now-stale pre-open position, behind the live playhead, and paged forward over already-played content. Those cues arrived behind the playhead and were dropped by the current-cue lookup until the read caught up, which is the activation delay. The anchor was correct for the instant it was captured; the gap was that the reader never re-sampled the playhead after the slow open. Not a crash, purely a latency at activation.

Fix. After the open and prewarm, the reader re-samples the live playhead and re-targets the single existing seek to it instead of the stale anchor (no extra network seek). A max(startAt, fresh) guards the direction so it never seeks behind the requested anchor, keeping it a no-op when paused, on a fast/local open, and on the seek re-arm path. The -2.0 bitmap SETUP lead-in is preserved on the new target, and the read-ahead snapshot is seeded from the re-sampled value so the first packet does not trip the park gate. The embedded subtitle reader started diagnostic now prints both startAt and effectiveStart.

Thanks to @reckloon for the precise report, including the isolating contrasts (pause-first and small/local both make the delay vanish) that pinned it to the slow open, and an accurate root-cause hypothesis with implementation watch-outs.

Full diff: 3.11.4...3.11.5