Summary. Seek-to-landed time on the native (loopback-HLS) path grew from a ~0.3 s median to ~1.2 s across the 6.6.0 → 6.7.0 window — same box, same titles, same scrub pattern. Software-path seeks are unchanged. A same-day, same-box pin-back A/B reproduces it: engine 6.6.0 lands a median 0.36 s, 6.7.0 a median 1.22 s.
Numbers (host seek instrumentation, seek-issued → engine-landed, direct-URL sources on a LAN PMS, 3rd-gen Apple TV 4K):
| title / path |
era |
n |
median |
max |
| 4K HEVC DV-P7 (native) |
6.5.6/6.6.0 multi-day baseline |
24 |
0.26 s |
1.97 s |
| same |
6.7.0 |
34 |
1.22 s |
8.30 s |
| same, same-box same-day A/B |
pinned 6.6.0 |
30 |
0.36 s |
5.42 s |
| 4K HEVC no-DV (native) |
baseline |
36 |
0.14 s |
0.44 s |
| same |
6.7.0 |
36 |
0.40 s |
0.90 s |
| SD MPEG-2 (software) |
both eras |
— |
~0.11 s |
unchanged |
| 1080p AV1 (software) |
both eras |
— |
~0.08 s |
unchanged |
Producer restarts stay fast throughout (8–34 ms in the logs); the added time sits between the restart and the landing.
Scope notes. The multi-second outliers appear on BOTH pins in the same-day A/B and are fatter than the multi-day baseline's, so we are not attributing the tail to this window — it looks scrub-pattern-dependent (bursts of coalesced presses) and may be its own story. The claim here is the median shift, which the pin-back isolates cleanly.
Suspect. The only change we can see on this path in the window is the range-boundary rework (the detour-fill fix — which works; the stutter it fixed is gone and we just closed that issue). A seek is a reposition, and a native-path landing involves several sequential reads (producer restart, segment rebuild, player re-buffer), so a small per-reposition cost would be paid several times per seek while staying under the software path's noise floor. That's inference, not measurement — happy to run an instrumented build or capture whatever timing you'd want around startPersistentConnection on a seek.
Summary. Seek-to-landed time on the native (loopback-HLS) path grew from a ~0.3 s median to ~1.2 s across the 6.6.0 → 6.7.0 window — same box, same titles, same scrub pattern. Software-path seeks are unchanged. A same-day, same-box pin-back A/B reproduces it: engine 6.6.0 lands a median 0.36 s, 6.7.0 a median 1.22 s.
Numbers (host seek instrumentation, seek-issued → engine-landed, direct-URL sources on a LAN PMS, 3rd-gen Apple TV 4K):
Producer restarts stay fast throughout (8–34 ms in the logs); the added time sits between the restart and the landing.
Scope notes. The multi-second outliers appear on BOTH pins in the same-day A/B and are fatter than the multi-day baseline's, so we are not attributing the tail to this window — it looks scrub-pattern-dependent (bursts of coalesced presses) and may be its own story. The claim here is the median shift, which the pin-back isolates cleanly.
Suspect. The only change we can see on this path in the window is the range-boundary rework (the detour-fill fix — which works; the stutter it fixed is gone and we just closed that issue). A seek is a reposition, and a native-path landing involves several sequential reads (producer restart, segment rebuild, player re-buffer), so a small per-reposition cost would be paid several times per seek while staying under the software path's noise floor. That's inference, not measurement — happy to run an instrumented build or capture whatever timing you'd want around
startPersistentConnectionon a seek.