Skip to content

5.28.1 - Cue placement survives the retained store

Choose a tag to compare

@superuser404notfound superuser404notfound released this 29 Jul 06:45
374916b

Follow-up to #233 from tresby's retest of 5.28.0. One fix, and it is the reason the placement work of 5.26.0 and 5.27.0 was invisible on half the sources it covers.

Fixed

  • SubtitleCue.placement reached the host on sidecars but never on an embedded track. 5.26.0 added the field and the decoders fill it correctly, but every operation that rebuilds a cue to change one field did it by calling the memberwise initializer with the fields it happened to know about. placement is defaulted there for source compatibility, so each of those call sites dropped it and still compiled. insertCueSorted is the decisive one: it stamps the session-monotonic id (#121) on every cue entering the retained store, so nothing arriving through the drained embedded path could deliver a placement at all, and the #107 text trim would have dropped it a second time on each teletext page transition. Cue rebuilds now go through one copy helper that carries every field it is not asked to change, at all eight sites, so the next field added to the cue cannot repeat this.

Three publishing paths exist and only one goes through the retained store, which is why this looked like a teletext defect rather than a general one:

Path Publishing placement before this release
Sidecar / external subtitle URL published as decoded survived
Native rendition route stored verbatim survived
Drained embedded track retained store dropped

That is the split the reporter measured: WebVTT placement worked through a sidecar, teletext placement did not because it is an embedded track. Colour and the other run attributes were never affected, since they live in the cue body, which every rebuild did carry, which is why 5.26.0's styling appeared to work end to end while placement did not.

Reported by tresby (#233), whose report located the loss between the decoder and $subtitleCues and named the decisive call site.

No API changes. A host that already reads SubtitleCue.placement now receives it on embedded tracks as well; one that ignores it is unaffected.