After a re-aimed restart, a PGS set whose clear is stranded below the producer floor overstays at the landing

[rrgomes]

On the 6.40.0 re-aim path (same 1080p H.264 ~35 Mbit/s MKV + PGS SDH asset as #408), a seek that re-anchors and restarts the producer can land showing the previous position's caption over the new scene. Reproduced on 6.40.0; 6.41.0's diff does not touch the subtitle store, so it should hold there. Two devices, same day, same build:

• Apple TV 4K 3rd gen: a coalesced far seek to 205 landed on target; the overlay then applied a set from half a minute earlier:

  [applySubtitleEvent] cueStart=33.200s cueEnd=4295000.495s sourceTime=15.256s engine.currentTime=205.000s seekGen=2
  

  The next authored set on the stream is 215.674, so the stale one stands ~10 s over the new scene's audio.

• M4 Pro Mac (controlled repro): drain seek target 199.1; boundary 196029 is not a random-access point (no sync sample covers it), re-aimed ×2, gate opened at actual=191983, 12.30 s flight. Post-landing, the picture at ~200 s renders under the 187.729 set (authored ≈2 s, a sound-effect caption):

  [applySubtitleEvent] cueStart=187.729s cueEnd=4295155.024s sourceTime=199.400s engine.currentTime=199.400s seekGen=10
  

  No stored subtitle packet exists in (191.98, 215.674). It cleared by ~206 on this hardware; the overstay scales with device speed and with the gap to the next authored set (we have watched the same shape run tens of seconds on the Apple TVs).

Mechanism as we read it: the re-aim's floor (191.98) lands past the 187.73 set, so that set's clear (~190) sits below the floor and can never be re-harvested — the store prunes behind the producer. The retained cue keeps end_display_time = UINT32_MAX, or the next-stored-packet close reaches the far-side successor (215.674) — a real packet, but not this set's successor, which is the #362 round-2 shape. closeOpenEndedCues(startingBefore:) does not cover it: the set starts inside the reconstruction window, not before it. Fast landings never show it — two control runs stepping +10 s with sub-second landings kept every caption correct.

Two candidate shapes, your call: close a bitmap set at min(next stored packet, start + a PGS dwell cap) when its own clear is unreachable; or a one-shot subtitle-stream harvest of [floor − gap, floor] after a re-aim, so the authored clear is read before the region is abandoned.

Full traces from both devices and screenshots available on request.

[superuser404notfound]

Reproduced and fixed, released as 6.42.0 (6e0ffb7b, fix commits ca31573c + 245cf494). Thanks for the two-device pairing and for the M4 run in particular: the controlled numbers are what made the geometry findable, and the case turned out to need a piece of bookkeeping that has been on the "named but not built" list since #362.

One correction to the premise, and it changes the fix. The packet store does not prune behind the producer. Since #125 its retention is byte-bounded only (32 MiB per stream, evict-oldest); the time-based prune was removed precisely because a backward seek into cache-resident content could land on packets it had evicted, and nothing re-harvests that region. So the clear at ~190 was not dropped, it was never READ: the run that harvested the 187.729 set was re-anchored before it got there, the re-aim's floor at 191.983 is above it, and nobody ever passed over the ground in between.

What the landing actually claims. A display set has no end of its own, so the reconstruction pass reads "no packet stored between this set and the playhead" as "this set is still up". Over ground nobody read, that silence is not evidence of anything, and the two faces you describe both follow from it: the set is seeded as the landing's active line, and alignCueEnds then closes it at the next stored packet, which is the far side of the authored silence rather than its successor. Your reading of closeOpenEndedCues is right too, it cannot help here: the set starts inside the reconstruction window, not before it.

#362 round 2 measured that the packets alone cannot show this. A reader restarted BEHIND leaves a descending harvest sequence at the boundary, which is what harvestGapCut reads; one re-anchored FORWARD hangs its packets in ascending order behind the stretch it skipped, so the pair is indistinguishable from an authored silence. A coverage ledger was named there as the precise signal and deliberately left unbuilt for want of a reproducible defect. This is that defect, so it exists now.

So the readers state what they read. SubtitleHarvestCoverage keeps one span per harvest run inside the packet store: the forward prefetcher reports its anchor, every in-place re-anchor and its read position as it goes; the pump's run begins where the producer opens or restarts (native and software paths) and reaches at least the playhead, since playback is rendering there, plus every packet it harvests. A set whose ground up to the playhead is not covered can no longer be the landing's active line, and the same rule closes the #100 stale hold's door onto the identical claim. A store nobody reports coverage to answers every span with yes, so a harvest path without notes behaves exactly as before.

Neither of the two shapes you offered, and here is the reasoning. A PGS dwell cap is an end nobody authored: to cut your two-second caption off before 199.4 it would have to be short enough to cut a long sign short in the same file, and three rounds of #362 went into removing laundered ends rather than adding one. The one-shot backfill is the better of the two and the ledger makes it possible now, but it spends a read of the skipped ground on a link that has just paid for a seek, and in your case it buys nothing the refusal does not: the authored state at 199.4 is an empty screen, which is what refusing produces, for free. What it would buy is the opposite case, a set that really IS still up while the proof is missing, and that needs an authored dwell long enough to span the whole unread stretch. If one turns up, that is the case that justifies the fetch, and the ledger can then name the exact span to fetch.

Measured on a 500 s H.264 + PGS fixture built to your geometry (set at 184, authored clear at 190, then silence to 240), served over a loopback origin, seeking from 100 to 197 so the initial run's park edge falls between the set and its clear while the restarted pump opens at 192, above it. Ten runs per arm:

arm	landing tick met the hole	stale CUE 184.00-240.00	landingWithheld=	authored set at 240
6.41.0	4/10	4/10 (every one of them)	0/10	10/10
6.42.0	6/10	0/10	8/10	10/10

Whether the landing tick meets the hole at all is a race with the re-anchored side reader: it repositions to target - 2 on the SUBTITLE axis, so it lands on the last clear before the target and stores exactly the packet whose absence is the case. That is the correction you watched arrive at ~206 on the Mac and much later on the Apple TVs, and it is why the same run on a local file reproduces only about half the time while a loopback HTTP origin reproduces every time. Controls, unchanged in both arms: a far seek into fresh ground landing inside an authored dwell still publishes its line, and a plain playthrough delivers the same cues with no withholding.

One thing about the Apple TV trace worth a second look before the retest. In that line sourceTime=15.256s sits 190 s below engine.currentTime=205.000s. That gap is the seek in flight, not a shift: the scrub clock snaps to the target while sourceTime keeps publishing AVPlayer's rendered position so subtitle consumers follow the picture rather than the target (#49). So that tick planned its window at 15.256 and the set it applied at 33.200 was ahead of THAT playhead, which is ordinary; the line that carries a landing's claim is the one whose sourceTime equals the landing, exactly like the M4's. If a caption still overstays there on 6.42.0, that line plus the #357 subtitle-delivery line beside it is what separates the two cases: landingWithheld=N means the claim was refused and something else is putting it on screen, its absence means the ground was covered and the claim was allowed.