4 Commits

Include renames

Author	SHA1	Message	Date
timothy	37674d6519	test(472): name the stale-playlist test for what it actually pins ... Third-round review caught that Stale_Playlist_Guard_Should_Take_Precedence_Over_An_Otherwise_Valid_Three_Way describes an impossible case: ThreeWay requires processLaunched <= playlistExists, which is exactly the negation of the guard condition, so the guard can never preempt a ThreeWay. What the test really pins is precedence over the progress branches (TwoWayLateProgress) — still the ordering that matters. That is the same "rationale misstates the mechanism" defect the previous commit existed to fix, landed inside the fix itself. Renaming rather than leaving a test whose name teaches the next reader something false. Also broadens the escape-hatch caveat: a stale playlist that slips past the guard lands as TwoWay more often than ThreeWay, since FFmpeg has usually not reported progress that early. Test name and comments only; no logic change.	2026-07-19 23:33:28 +02:00
timothy	58b93d3e3d	docs(472): correct the stale-playlist rationale; pin guard precedence ... Re-review of the fix commit returned MERGEABLE with one Medium: the comment justifying the stale-playlist guard misstated the mechanism, in three places. It claimed Run "warns about a non-empty transcode folder but does not delete it" — but StartFFmpegSessionHandler.FolderMustBeEmpty calls EmptyFolder BEFORE the worker spawns, and Run's finally empties it again. Verified directly rather than taken on the reviewer's word. The real residual path is EmptyFolder FAILING: it swallows every exception into a LogWarning and continues. Say that instead. On a PR whose entire value is that the numbers mean what they say, a rationale comment that misstates the mechanism is the same class of defect the PR exists to prevent, so it does not get to ship as a nit. Also documents that the guard is best-effort rather than a proof (if the wipe failed, before-or-after-launch is a scheduling race, so an unlucky sample can still slip through as an implausibly fast ThreeWay), and adds the test the reviewer noted was missing: guard precedence over an otherwise-valid ThreeWay. Comments and one test only; no logic change.	2026-07-19 23:21:03 +02:00
timothy	757fb76151	fix(472): review fixes — honest bucket boundaries, stale-playlist guard ... From the cold adversarial review of the initial diff. No blockers were found; these address what the numbers MEAN, which is the whole point of an instrumentation change. - The buckets span the worker's Run entry, not the startup stopwatch, so prep overlaps the tail of `setup`. Rather than let the log imply an invariant it does not satisfy, say "spans runEntry" in the line, spell it out in the doc comment, and rename the test that had codified the false `sum == startup` claim. - Guard `processLaunched > playlistExists` -> Unavailable: a stale live.m3u8 from a previous session (Run warns about a non-empty transcode folder but does not delete it) would otherwise yield a plausible-looking sample whose prep exceeds the measured phase. - Split the two-way fallback into TwoWay vs TwoWayLateProgress. They are different stories about the pipeline and discriminating stories is what this issue is for. - Document the 100ms playlist-poll quantization (it lands entirely in firstGop, the smallest bucket) and the first-process-failed case where ffmpegInit spans a retry. - Short-circuit the per-line timestamp call; static readonly Unavailable. - Tests for the new guard, progress-before-launch, and boundary equality (so tightening >= to > later cannot pass silently).	2026-07-19 23:05:14 +02:00
timothy	d91d6ee1ed	feat(472): sub-split the HLS cold-start startup phase ... #350's measurement showed `startup` is 81% of tune-in latency and carries 100% of its variance, while remaining one opaque bucket spanning FFmpeg spawn -> input open/probe -> encoder init -> first GOP. Two hypotheses survive that measurement (NFS input open vs VAAPI init under contention) and they need opposite fixes, so split before optimizing. Adds `prep` (ErsatzTV-side work before FFmpeg exists) + `ffmpegInit` (launch -> first `-progress` output) + `firstGop` (-> live.m3u8 exists) to the existing Information-level cold-start line. The pipeline runs `-loglevel error -nostats -hide_banner`, so a healthy FFmpeg writes nothing to stderr; the `-progress` stream is the only zero-cost milestone available and `ffmpegInit` therefore still lumps input-open with encoder-init. That limit is documented rather than papered over, and the split degrades to the two-way form #472 accepts when no progress arrives before the playlist. Log-only: no transcode behavior change, no new endpoint or config knob. fixes #472	2026-07-19 22:49:07 +02:00