477 Commits

Include renames

Author	SHA1	Message	Date
timothyandClaude Fable 5.1	d6e4426aa9	docs(563): retire the forward-references the supersession falsified, and trim the record to what only it says ... Two pointers still named #563 as the open reason scripted playout has no coverage. The ContentEnumeratorBuilderTests header now points at the successor record and docs/testing.md instead of the issue this branch closes. docs/decisions.md carried an orphaned fragment, "external-process pipeline remains #563's", in the residual block under ## Index -- with the pipeline now permanently outside the automated suite rather than deferred, the fragment states something false and has no recoverable subject to rewrite it around, so it goes. The record's rule gains the two things measurement settled: that ApiJsonSettings shares production's configuration and never MVC's settings object (MaxDepth 32, the two ProblemDetails converters, pinned by ApiJsonSettingsTests), and that a fixture must aim every trimming instruction between two content boundaries or that action's trim argument is witnessed by nothing. Its body loses the mutant table and the extraction paragraph, which the mechanics doc its own frontmatter points at carries verbatim; what remains is the conclusion plus the reasoning that exists nowhere else. 70 prose lines to 56, under the advisory ceiling without dropping a distinct finding. Refs #563 Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:25:11 +02:00
timothyandClaude Fable 5.1	b3bc3ed115	test(563): pin per-item guide-group advancement, which mutant b showed was unmeasured ... Removing SchedulingEngine.AddCountInternal's _state.AdvanceGuideGroup() left both guide-group assertions green: the locked-group test only compared inside/outside the group, and the snapshot only compared item 2 to item 0. Assert the actual sequence instead. Refs #563 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:25:11 +02:00
timothyandClaude Fable 5.1	02ecd484ed	test(563): characterize the scripted engine build API in-process and replay a committed script fixture through the real controller ... #381 deferred Scripted from the playout golden net because ScriptedPlayoutBuilder shells out via Cli.Wrap to a user-authored program that drives SchedulingEngine over HTTP loopback. #563 offered two arms: a full process+Kestrel integration harness, or expanded engine coverage with the shell-out scoped out. This takes the second arm, but delivers the first arm's "documented in-process stand-in" so the scope-out is a measured claim rather than a prose one: - SchedulingEngineTests grows from 1 test to 21, covering AddCollection/AddCount/ AddAll/AddDuration/PadUntilExact, EPG guide-group locking, per-item history, the 20-call no-progress halt and its reset, and the anchor round-trip a Continue build restores from. Unknown-content-key cases assert false AND that nothing was scheduled. - ScriptedScheduleControllerTests replays Fixtures/scripted-build.json through the real ScriptedScheduleController + ScriptedPlayoutBuilderService.MockSession + SchedulingEngine and pins a 13-item snapshot in the golden line format, so there is exactly one action->engine mapping under test — the production one. It also pins the three mappings the predecessor record's "1:1 pass-through" wording hides: 404 on an unknown build id, 400 on an unparseable playback order, a SILENT fall back to FillerKind.None on an unparseable filler kind, and the InvalidOperationException -> 400 translation. MockSession was declared on IScriptedPlayoutBuilderService with zero callers; it is the seam this needs and now has one. Both fixtures are TZ-independent by construction (Chronological order plus only instant-preserving instructions) and verified passing, not skipping, under TZ=UTC, America/New_York, Australia/Lord_Howe and Asia/Kathmandu. Refs #563 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015QqCpYFsKgnAnx6jVwrKiV	2026-09-05 09:25:11 +02:00
timothyandClaude Fable 5.1	a7d91bf15a	fix(876): sweep session narrative out of hooks, workflows, scripts, tests and code comments; grow the detector to the process corpus ... `docs.no-session-narrative` reaches every durable artifact, but its detector scanned only `docs/**/*.md` and root markdown, and nothing had ever swept the rest. The issue named four sites from one grep and called them a floor. Deriving the population instead — a whitespace-joined sweep over every tracked file outside the detector, for the detector's own phrasings plus the attribution and review-round class #812 found — gave 453 sites in 108 files at `fb5592971`, and a second pass for phrasings the first list missed (hyphenated `round-N`, "an earlier version", "the reviewer proved") added residuals in the same files. Every site was classified with #812's three dispositions (CUT / SEVER / KEEP with its sub-kind) under the who-benefits test; the per-site manifests are on the PR. The rejected designs, tested-and-rejected fixtures, measurements and traps stay; the attribution of who found them and the round in which they were found go. The detector's population grows to `.claude/`, `.gitea/`, `.husky/` and `scripts/` regardless of extension, minus the detector and its own test (whose fixtures ARE the phrasings) and minus `scripts/tests/fixtures/` (test data, including decision-record copies — the same reasoning as the records' own exemption, and what keeps the record's depth measurement true), and `--all` lists tracked REGULAR files only — a symlink's content is its target and a gitlink has none. The #812 argument for leaving `docs/superpowers/**` in the population runs the other way here: `--diff` sees only ADDED lines, and 287 of the 453 sites were under 30 days old — this corpus is where narrative is being added, so the advisory nudge has reach. Density agrees: 56 line-mode hits over the 113 regular files the predicate admits, against 9 over 66 docs files before #812. `web/` and C# stay out on the same measurement (3 of 74 PATTERNS-matching sites, ~4,600 files). The predicate did not grow: PATTERNS matched 74 of 453 sites, and widening the word list to the attribution class is the treadmill the withdrawn parity test ran on. The population oracle is restated over segments with the new arms, the synthetic cross product gains the process heads and non-markdown extensions, a fixture witnesses that a tracked symlink is neither scanned nor counted, a `.py.bak` axis separates a by-name exemption from a `startswith` over the same tuple, and eight mutants (drop the process arm, drop the by-name exemption, exempt by `startswith`, drop or add a prefix, drop the fixtures exemption, list only markdown, drop the symlink filter, test the mode per row instead of per path) each redden it. A pre-existing silent drop in `--diff` goes with it: git tab-terminates a `+++` filename that contains a space, and the kept tab made `is_scanned_path` refuse the file with no notice — fixed, with a positive control and its own mutant. Code is unchanged by construction, measured per file type against `origin/main`: Python modules are AST-equal with docstrings stripped, except `#` lines inside the embedded fixture programs (string literals) of three test modules; workflows differ only in `#` lines inside `run:` block scalars; shell, C#, TypeScript and jq are equal with comment lines stripped. The stated exceptions: the detector and its test, 26 vitest titles that carried review-round or severity labels or a reviewer attribution (call sites whose title changed — every changed title line walked back to its `it(` / `it.each(...)(` anchor, so a `' + '` concatenation counts once), two registry note strings and the mutation manifest's prose fields. scripts/tests: 1565 passed. Web: lint, typecheck, 1319 tests green. Closes #876. Decisions-Edit: yes Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PEcBoFw7ctrf3Nb7R7x7wk	2026-09-03 20:51:39 +02:00
timothyandClaude Opus 5	3951fcf516	fix(823): stop patching the record by grep — a second ?? [] survived, and my "swept it" claim was false ... Round-four review. One HIGH, again in the decision record, and the previous commit message asserted this exact class was cleared. It was not. THE HIGH, and the reason it recurred. A second sentence still described the rejected reading: "The guard form is `?? []` into a local rather than this record's Optional(x).Flatten(), a STATED deviation". The shipped guard is `?? AllDaysOfWeek()`. That sentence is the one that dictates guard FORM to the next implementer, so it would have taught the `[]` reading the same record spends a paragraph calling data corruption -- and it had already propagated into docs/decisions/README.md, the mandated entry point, which carries `rule:` verbatim. The mechanism, not the sentence, is the defect. I swept with a regex keyed on "null" plus a reading word; this sentence talks about guard FORM and contains neither, so it could not match. That is grepping the retracted WORDING instead of sweeping the CONCEPT, which is exactly what this corpus warns about -- and three rounds in a row have now found a defect introduced by the previous round's targeted string edit. So the fix is not another targeted edit: the whole `rule:` field was split into its 39 sentences and read back one by one against the code. Everything below came out of that pass rather than a grep. Its secondary damage is worth recording because it is the shape of a rationale that outlives its claim: the deviation was justified by ".ToList() allocates for nothing", which is now BOTH irrelevant to the choice AND false about the shipped code, since AllDaysOfMonth()/AllMonthsOfYear() are themselves Enumerable.Range(...).ToList() on exactly the null path it describes. - The opening sentence of `rule:` prescribed Optional(x).Flatten() as THE read-site form. It is the sentence most likely to be read in isolation, and it is wrong for six of the eight columns. It now separates the universal half (a LOCAL, never assigned back) from the half that is not (the substituted value), and names where each applies. - `signals:` had never been touched, so roughly 60% of `rule:` was unreachable by the discovery surface built for it -- no AlternateScheduleSelector, no mapper, no "unrestricted", and its paths: list named none of the files this work touched. It also advertised "Optional Flatten hoisted local" as the form, which is precisely what the six do NOT use. - The body prose was still entirely about SongMetadata while `rule:` had grown a whole second subject. Added the two results that contradicted the prior reasoning, in prose, where a reader meets them. A REAL BUG in my own guard, not just prose: fixture.IsAbstract.ShouldBeFalse(...) A C# `static class` compiles to `abstract sealed`, and NUnit runs tests declared in one -- this repo already has such a fixture (AlternateScheduleSelectorTests is `public static class`). So the check I added one commit ago to reject an un-runnable fixture would have falsely reddened a perfectly good static one. Now rejects an abstract BASE (abstract and NOT sealed), which is the case NUnit actually cannot instantiate. A SURVIVING MUTANT the added controls did not kill: AnyDate was 2024-03-06. With a day <= 12 a CROSS-WIRED substitution survives the whole fixture -- `DaysOfMonth ?? AllMonthsOfYear()` hands back 1..12, which still contains day 6, so every assertion passes while the guard substitutes the wrong set. Moved to 2024-03-20, still a Wednesday in March, outside 1..12. Measured both ways rather than reasoned: the cross-wire mutant passes the old fixture and FAILS 2 of 11 on the new one. Also re-witnessed, because I had modified that file and never re-proved it: restoring `??=` in LuceneSearchIndex reddens the LUCENE fixture (1 red, 1 green) -- the exact mirror of the Elastic mutation. Extracting ThrowOnWarningLogger did not cost #701 its proof, and the two fixtures are independently load-bearing in both directions. The record is now 73 prose lines, over the 60-line WARNING ceiling. Stated rather than trimmed: it is 42nd of 42 records over that line, and the added content is distinct findings (a second subject, a migration analysis and three residuals), not redundancy against a sibling. Local gate: ErsatzTV.Tests 2091 passed / 6 skipped (the three fixtures' MySQL halves), Core.Tests 697/1 -- 0 failures. Format clean, no BOM. decisions validate OK. Refs #823 Refs #824 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019zUmJZHhVP7kXg5DV237TW	2026-08-29 21:00:22 +02:00
timothyandClaude Opus 5	ea888011aa	fix(823): the decision record argued BOTH readings — and the per-dimension mutant that survived the fixture ... Round-three review findings. One HIGH, and it was in the durable artifact rather than the code. THE HIGH: the record stated the shipped reading and its inverse. The semantic reversal (empty -> unrestricted) rewrote the residual and the write-half of `media.nullable-primitive-collection-mutation` but left the ORIGINAL reasoning standing two sentences earlier: "A null reads as EMPTY, so the item matches nothing"; "the REJECTED alternative was the All*() set"; "SKIPPING the row is the conservative repair". The shipped code is `?? AllDaysOfWeek()` -- precisely the alternative that passage calls rejected. The previous commit then inserted residual (1), which reasons entirely FROM the All*() reading, two sentences after the sentence denying it. That is worse than a stale comment. A session resolving this key -- or reading the MemPalace mirror, which carries `rule:` verbatim -- would have been told to write the guard the other way, i.e. talked into the `[]` reading that the same record elsewhere argues is data corruption one save later. Replaced the whole passage, then swept the record for every other mention of the empty reading rather than trusting the one replacement: the only survivor is the new sentence that records EMPTY as the rejected alternative, which is the direction that stops it being re-adopted. THE MEDIUM: one arrangement did not close the hole it claimed to. The discriminating control added last commit nulls DaysOfWeek against a restrictive MonthsOfYear. It excludes "any NULL matches unconditionally" only for that dimension. The review supplied the surviving mutant -- `if (item.MonthsOfYear is null) { return item; }` ahead of the checks -- and traced it green through all nine tests. Verified by EXECUTION, not by reading: applied to the previous fixture it passes; applied now it FAILS 1 of 11. Each of the three dimensions is now nulled against a restriction on a different dimension. The rest, all from the same round: - The coverage guard's test detection listed attribute TYPES, and each list falsely reddened whatever it omitted: TestAttribute alone missed [TestCase], and the three-type replacement missed [Theory]. Now decided by NUnit's own ITestBuilder/ISimpleTestBuilder interfaces, which cannot fall behind the vocabulary. It also dropped BindingFlags.Static (GetMethods() defaults to including it), which would have falsely reddened a static test method. - The same guard accepted an ABSTRACT fixture -- NUnit never instantiates one. The indexer population already filtered IsAbstract; the fixture side now mirrors it. - The record's `mechanics:` still described the old `[Test]`-only clause, in the same file the change edited. - An <inheritdoc> made the ProgramScheduleAlternate empty-case test inherit a docstring written from the PlayoutTemplate test's viewpoint. Two more mutations executed: - `if (item.MonthsOfYear is null) return item;` -> 1 red, 10 green. This is the mutant that survived the previous head; it no longer does. - an abstract type named in the covered set -> coverage guard red. Local gate: ErsatzTV.Tests 2091 passed / 6 skipped (the three fixtures' MySQL halves, skipping visibly without ETV_TEST_MYSQL_CONNECTION), Core.Tests 697/1 -- 0 failures. Format clean, no BOM on the touched set. decisions_validate OK. Refs #823 Refs #824 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019zUmJZHhVP7kXg5DV237TW	2026-08-29 20:43:07 +02:00
timothyandClaude Opus 5	6200713965	fix(823,824): close the review round's findings — a discriminating control, the second mapper's empty case, and honest test detection ... Follow-up commit (the branch is pushed, so not an amend). Two more cold reviews landed on the previous head; both reported 0 Blocker and 0 High, and these are their Mediums and Lows. Each fix carries its own witnessed mutation. 1. The selector fixture could not tell the fix from a much broader one. Every null test set a NULL and expected the item SELECTED, so all of them pass equally under "NULL means unrestricted" and under "any NULL makes this item match unconditionally" -- a refactor short-circuiting the whole date check on any null kept them green. Added the discriminating control: a NULL DaysOfWeek paired with MonthsOfYear = [1] against a MARCH date must be None. Only the narrow reading passes. 2. A_Null_Item_Does_Not_Disturb_Selection_Of_A_Later_Item never measured its own docstring. The nulled item was unrestricted and at Index 0, so it always won and the second item was never evaluated -- the stated invariant ("a null on the first item must not decide the second") went unmeasured while the test passed. Split into two: one where the nulled item genuinely does not match, which measures that the loop CONTINUES; and one that pins the index-order win separately. 3. The empty-preservation control existed for one of two identical mappers. The anti-mutant test for "empty or null becomes All*" covered only Playouts.Mapper; Scheduling.Mapper is a byte-identical triple in another file and had none, so a defensive edit to it alone would have rewritten a deliberately-empty user selection to 1..31 with the suite green. That is the one-helper-two-callers shape this repo has been bitten by. Added the matching test. 4. The coverage guard's [Test] clause did not check what its message claimed. GetMethods() without BindingFlags returns INHERITED methods, so a fixture that merely subclasses another satisfied it while driving the wrong indexer -- and Values.Distinct() cannot catch that, since the two Types differ. It also matched TestAttribute alone, so a future fixture written as [TestCase] would have falsely reddened, and it accepted an [Explicit]/[Ignore]d fixture that never runs, which is the "wired is not running" failure the guard exists to prevent. Now DeclaredOnly, the full test-method vocabulary, and Explicit/Ignore rejected at both method and fixture level. 5. Three residuals recorded on media.nullable-primitive-collection-mutation that the previous head asserted nothing about: - the LOUDNESS change, worst for an all-three-NULL ProgramScheduleAlternate, which now matches unconditionally and shadows the default schedule where it previously threw. Unreachable today, and a choice over an unreachable state rather than a measured requirement -- said plainly. - the normalization is ONE-WAY and WHOLE-LIST: both PUT paths are full replaces, so editing any row persists All*() over EVERY NULL row in that playout, and afterwards "the operator selected all 31" and "this is a legacy row" are indistinguishable. An ordinary user action closes that door. - the WRITE side disagrees with the READ side about what ABSENCE means: an omitted daysOfWeek normalizes to [] ("never applies") while a NULL column reads as unrestricted, so an API client gets HTTP 200 and a row that silently never fires. Filed as #880 rather than folded in here, because a client omitting a field on a write is a different question from what a legacy NULL meant. Two more mutations executed, both witnessed: - DaysOfWeek guard disarmed in Scheduling.Mapper -> 1 red, 3 green. - A fixture with no DECLARED test named in the covered set -> coverage red. Local gate (MySQL lane armed): ErsatzTV.Tests 2097 passed / 0 skipped, Core.Tests 695/1 -- 0 failures. Format clean, no BOM on the touched set with the population count asserted. decisions_validate OK. Refs #823 Refs #824 Refs #880 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019zUmJZHhVP7kXg5DV237TW	2026-08-29 20:27:33 +02:00
timothyandClaude Opus 5	95b2700f09	fix(823,824): a scheduling NULL collection reads as UNRESTRICTED and is guarded at both read sites; the Elastic indexer gets its own mutation proof ... Both issues are #701 deferrals, and they land together because both rewrite the same decision record. #823 -- can a null reach one of the six collection-valued scalar columns? MEASURED against a real TvContext on BOTH providers (SQLite, and MySQL 8.4 on an ephemeral server), because the reasoning available beforehand pointed the wrong way. The two converters differ on their read side -- IntCollectionValueConverter maps null-or-blank to Array.Empty<int>(), while EnumCollectionJsonValueConverter would dereference the result of JsonConvert.DeserializeObject -- so the expectation was that a NULL row behaves differently per column. NEITHER RUNS: EF does not invoke a value converter for a NULL column at all. All six materialize as CLR null, the int converter's null-to-empty branch is dead on this path, and unguarded each .Contains in AlternateScheduleSelector throws NullReferenceException. A NULL reads as UNRESTRICTED -- the All*() sets -- not as empty. This is the whole semantic question and the first draft got it backwards. It is decided by the one NULL reachable WITHOUT any code writing one: Sqlite's 20240113140741_Add_PlayoutTemplate_DaysOfMonth adds the column with nullable:true and NO defaultValue, so a PlayoutTemplate row inserted before it holds NULL and by construction had no day-of-month restriction. Reading that as empty INVERTS the row's meaning and silently stops the template applying at all. All*() preserves it, and is how "no restriction recorded" is already represented (GetPlayoutAlternateSchedulesHandler, PreviewBlockPlayoutHandler). What does NOT decide it, and was wrongly cited in the first draft: the API request records normalize an omitted field with `?? []`, but that is a client omitting a field on a WRITE and says nothing about what a legacy database NULL meant. Two read sites, not one. Guarding only the selector would have left the entity->DTO mappers unguarded, and those feed the SPA: PlayoutScheduleEditors spreads the collection (`[...template.daysOfMonth]` -> TypeError on a JSON null) and playoutTemplateCalendar's appliesToDate -- an exact port of GetScheduleForDate -- calls .includes on it. Both mappers now substitute the SAME defaults, so the preview agrees with what is actually scheduled. Neither guard is assigned back onto the entity, which is the media.nullable-primitive-collection-mutation mechanism. Reachability, stated precisely rather than overclaimed. All six are nullable:true on both providers, but a nullable column does not produce a NULL row: five of the six were present at CreateTable, so a NULL there still needs code to write one, and on MySQL there is NO code-path-free NULL for any of the six. The write path ACCEPTS a null (SaveChanges succeeds, stores SQL NULL) but no caller supplies one today -- every production construction of the two commands goes through the request records. That is a property of the code, not a live caller; claiming otherwise would be the banned "it's AsNoTracking today" argument pointed the other way. #824 -- ElasticSearchIndex.UpdateSong had no regression test Issue option 1 (a non-network transport) shipped, and needed no new package: Elastic.Transport.InMemoryRequestInvoker is public in the pinned version and ElasticsearchClientSettings(NodePool, IRequestInvoker) accepts it, injected into the private _client the way #701 injects the Lucene IndexWriter. UpdateItems never runs `_client ??= CreateClient()`, so the injected instance is the one used. Two traps there are load-bearing, both measured: the canned response must carry an `X-Elastic-Product: Elasticsearch` header or the client's product check throws UnsupportedProductException INTO UpdateSong's catch, and an empty body fails to deserialize the same way. Either turns the fixture into a green measurement of the error path -- which is how it first failed here, caught by the ThrowOnWarningLogger. The document id is asserted as the LAST PATH SEGMENT, not by substring: the index name carries digits, so ShouldContain would stop discriminating for a song whose id collided with one. Six mutations executed, each disarming ITS OWN clause alone: - `??=` restored in ElasticSearchIndex only -> the Elastic fixture reddens on "metadata.Artists should be null but was []" while the LUCENE fixture stays GREEN. The #824 hole demonstrated, not described. - DaysOfWeek guard disarmed in the selector -> 4 red, 3 green (DaysOfMonth and MonthsOfYear unaffected). Each clause is independently load-bearing. - DaysOfMonth guard disarmed in Playouts.Mapper -> 1 red, 2 green. - Elastic dropped from the covered set / mapped to the SAME fixture as Lucene / mapped to a class with no [Test] -> SearchIndexMutationCoverageTests reddens on each. That coverage guard is the boundary fix the issue asked for: the covered set is compared against an ISearchIndex population DERIVED FROM THE ASSEMBLY. Its claim stops where the check does -- no static check can establish that a named fixture actually DRIVES its indexer, so it forces a human to look rather than proving coverage. ThrowOnWarningLogger moved to ErsatzTV.Tests/Support so both fixtures share it; the Lucene fixture's assertions are otherwise untouched, since it is a witnessed proof artifact. No production change in ElasticSearchIndex.cs -- #824 is coverage only. Docs: testing.md gains a "Provider-parity fixtures" section naming all THREE opt-in-MySQL fixtures and recording that CI runs none of them (#627); docs/README.md gains the matching task signal; guard-inventory.md's hand-written C# guard list goes from five files to six. Scheduling/Mapper.cs loses the UTF-8 BOM it inherited, per #311 fix-as-you-touch. Local gate (with the MySQL lane armed): ErsatzTV.Tests 2096 passed / 0 skipped, Core.Tests 693/1, Infrastructure.Tests 114, Architecture.Tests 7, Scanner.Tests 1504 -- 0 failures in each. scripts/tests 1228 passed / 2 skipped. dotnet format whitespace --verify-no-changes clean; BOM check over the touched set with the population COUNT asserted, because a bare zsh loop silently checks one concatenated filename. decisions_validate OK. Fixes #823 Fixes #824 Decisions-Edit: yes Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019zUmJZHhVP7kXg5DV237TW	2026-08-29 20:02:52 +02:00
timothyandClaude Opus 5	a4700185b2	fix(691): guard SongMetadata.Artists/AlbumArtists at the domain boundary ... SongMetadata.Artists and .AlbumArtists are nullable EF primitive collections that FallbackMetadataProvider.GetSongMetadata never assigns, so untagged songs persist them as NULL. SongVideoGenerator dereferenced both unguarded (metadata.Artists.Count, string.Join, AlbumArtists.Filter(...Artists.Contains...)), throwing NRE/ANE during song-video generation on the playback path. Rather than enumerating and guarding each read site (the same mistake that left these unswept after #671), add backing fields to the two properties whose getters coalesce null to an empty list. EF Core's default PreferField access mode reads/writes the raw backing field during materialization and change-tracking (confirmed by running the full ErsatzTV.Tests suite, including SongMetadata round-trip tests, unchanged), while every other caller -- SongVideoGenerator, MediaCollectionRepository's rerun-collection artist grouping, and any future reader -- goes through the property getter and always sees a non-null list. This subsumes the ad hoc `metadata.Artists ??= []` guards already hand-applied in LuceneSearchIndex/ElasticSearchIndex and the `?? []` in LibraryBrowseItemMapper, which remain but are now redundant. Adds SongVideoGeneratorTests covering an untagged song (null Artists/ AlbumArtists) through GenerateSongVideo; verified RED (NRE at SongMetadata.cs's Artists getter) by reverting only the `??= []` clause, not the file. Strips the pre-existing UTF-8 BOM from SongMetadata.cs per the #311 formatting gate (touching a legacy-BOM file makes stripping it ours to do). Refs #691 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 21:30:06 +02:00
timothy	bc1a37ff01	fix(510): pin the blank-guard's is-Custom discriminator, verified by mutation ... Round-4 review found the fall-through tests, while now falsifiable, still did not pin the whole guard. Two gaps, both closed and both verified by running the mutation rather than by asserting the test would catch it: 1. All three fall-through tests used only " ", so narrowing IsNullOrWhiteSpace to `image == " "` would have passed while breaking fall-through for null and "" -- and null is the form the API actually persists. Parameterized over null, "" and " ". 2. Nothing pinned the guard's `ImageSource is Custom` clause. This is the sharper of the two: a ChannelLogo watermark's Image is NORMALLY blank (the API writes Image = null for every non-Custom source), so dropping the discriminator would send every playout-item ChannelLogo watermark down the fall-through path instead of resolving the channel's own logo -- with a fully green suite. Added Blank_Image_ChannelLogo_Playout_Item_Watermark_Should_Win_And_Not_Fall_Through, which distinguishes the two levels by watermark Id so a fall-through is observable even though both resolve to the same cached path. Mutation results (each mutation applied on its own, then reverted): drop `is Custom` from the guard -> 1 failure, and the new test is the ONLY test that catches it IsNullOrWhiteSpace -> == " " -> the null and "" parameterized cases fail Negative control re-measured on the final 32-case fixture: 19 fail against the origin/main resolver. The 13 that pass both ways pin deliberately preserved behavior plus the positive control, which the record now states explicitly along with the mutation table. This round's lesson, recorded in the record: a test's NAME is not evidence it pins what it claims, and a whole-file revert cannot show that a test aimed at a specific clause actually reaches that clause -- only mutating the clause can. Gates: 2661 tests green across 4 projects, 225/225 script tests (the gate I skipped before the last push), decisions-validate OK, format exit 0, no BOMs. refs #510	2026-07-26 21:53:01 +02:00
timothy	edf8be4b5e	fix(510): re-review round — make two review-added tests actually falsifiable ... Re-review of the previous fix commit found that two tests added to close round-1 findings could not fail. Both verified before fixing: 1. Missing_But_Named_Custom_Playout_Item_Watermark_Should_Not_Fall_Through gave the channel-level fallback the SAME missing custom path as the playout-item watermark, so a wrongly-widened guard would have fallen through to a fallback that also resolved to None -- the assertion held either way. The fallback is now an independently resolvable ChannelLogo whose cached file exists, so a fall-through returns it and fails the test. Added the matching positive control (blank -> falls through and DOES return that logo), so the pair shows the guard distinguishes blank from unresolvable instead of both landing on None. 2. Deco_With_One_Valid_And_One_Missing_Watermark... asserted a filtered list length while the routing claim the decision record cited it for lives in FFmpegLibraryProcessService.CanUseFFmpegNativeWatermark, which the test never called. It now calls the real predicate. Also, three wrong claims of my own: 3. The Resource arm comment said "nothing in the app writes a Resource watermark to the database". False -- CreateWatermarkHandler and UpdateWatermarkHandler persist whatever ImageSource the request names, so a Resource watermark IS creatable through the API, always with Image = null. That is precisely why the new null guard is load-bearing, so the comment was arguing for its own removal. 4. "One resolver and no per-caller policy" contradicted the surviving playout-item blank-Custom fall-through documented a few lines later. Reworded in both the record and the XML docs: one resolver, and exactly one piece of per-caller policy which lives in the CALLER. 5. The record's "12 of 18 new tests fail pre-fix" was stale. Re-measured against the final fixture: 19 of 29. The other 10 pass both ways by design because they pin preserved behavior, which the record now says explicitly rather than leaving the gap to be read as weakness. Removed the vacuous generated-URL test rather than keeping it with an honest comment -- an empty list trivially contains no URL, so it implied coverage it never had. Its assertion is folded into the sibling test that has a real arrangement. Gates: 2772 tests green across 5 projects, dotnet format exit 0, no BOMs, decisions-validate OK, live-E2E re-run against this binary (0 changed pixels, nameplate absent, warning emitted). refs #510	2026-07-26 21:29:11 +02:00
timothy	1a7f15fb27	fix(510): address independent review — Resource null guard, honest routing claim ... Two independent reviews (cross-family Codex + cold Opus) both returned BLOCKED. Findings, all verified against source before acting: 1. Resource arm could throw ArgumentNullException (Codex, Medium). Making the channel/global Resource arm reachable exposed that CreateWatermarkHandler and UpdateWatermarkHandler write `Image = null` for EVERY non-Custom watermark, so an API-created Resource watermark reached Path.Combine(folder, null). Added the blank/null guard the arm never had. This was live at the playout-item level too, not just newly-reachable code. 2. "Routing is unaffected" was false (Codex, Low but sharp). The predicate is unchanged, but CanUseFFmpegNativeWatermark also tests Count == 1, and dropping an unresolvable watermark shortens the list. A deco with one valid and one missing permanent watermark now routes ffmpeg-native where it previously routed to the graphics engine. Intended, but observable -- so it is documented and pinned by a test rather than claimed away. 3. "Exactly one resolver" over-claimed (Opus, High). True of the selector, not the application: the song-progress overlay is built as a WatermarkOptions directly by the streaming and troubleshooting handlers, unchecked, and can still hand ffmpeg a nonexistent -i. Pre-existing; scoped the claim in the record and channels.md and filed #653. 4. Undeclared crash->degrade change (Opus, Medium). Channel/global Custom had no blank-image guard, so a cleared image hit ImageCache's fileName[..2] and threw out of stream startup. Now declared in the record and tested. 5. Contradictory rule text (Opus, Medium) -- the catalog one-liner said "always no bug" while the body documents the playout-item fall-through exception. Qualified; catalog regenerated. 6. History was wrong in both the record and the XML docs: the three precedence levels did NOT all check every source -- channel/global had no Resource arm and threw. Corrected. Tests: 30 in the fixture now (was 18). New coverage for the preserved blank-Custom fall-through (to channel AND to global), the complement case (missing-but-named must NOT fall through), null/blank Resource, and the valid+missing routing case. 17 of 24 failed against the pre-fix resolver before this round; the fixture stays mutation-sensitive. Also: hoisted the mock-filesystem Initialize() out of its loop so a multi-file case cannot silently seed only the last file, and marked the generated-URL test honestly as redundant-by-construction rather than claiming independent coverage. The decision record is now 81 prose lines, over the 60-line ceiling. Declared as a legitimate decline per docs.corpus-size-signal: the length is the review findings above, each a distinct fact, not redundancy. refs #510 #652 #653	2026-07-26 21:12:13 +02:00
timothy	9cbe70e486	fix(510): one watermark resolver for all four attachment points ... WatermarkSelector resolved watermarks in two places with two policies. The three precedence levels (playout item, channel, global) existence-checked every image source and degraded to None; the deco path had its own copy of the same switch that returned whatever path it computed, unchecked. So one channel could disagree with itself about whether an on-screen bug rendered, based only on how the watermark was attached. #502 deferred this here but scoped it to ChannelLogo. It was never ChannelLogo-only: the deco path skipped the existence check for Custom and Resource too. Extract one ResolveWatermark used by all four sites. Severity is not cosmetic. A dead LOCAL path is not harmlessly skipped -- CanUseFFmpegNativeWatermark hands a single permanent watermark to ffmpeg as a bare -i argument and excludes only URLs, so the deco path could hand ffmpeg a nonexistent input file. The generated-initials nameplate was real: a live-E2E on a real transcoded frame confirmed it composited via the deco path (/iptv/logos/gen is on ArtworkController, which has no auth filter, so the container-internal self-fetch succeeded). The #502-era comment claiming "it has never rendered here" was wrong, and the new record says so. It is still removed: serving it means an HTTP fetch inside stream startup, which graphics.channel-logo-caching (#525) eliminated for logos, and it depends on #1's hardcoded localhost. Reviving it by caching the image instead is #652. Measured blast radius on prod: 0 Deco rows, 0 DecoWatermark rows, all 43 channels have logo artwork -- no rendered output changes. Preserved deliberately: a playout-item Custom watermark with a blank image still falls THROUGH to the channel/global watermark; unifying resolution must not change which watermark wins. Routing is untouched. Strict improvement: the channel and global arms previously threw NotSupportedException on a Resource watermark; they now resolve it. The default arm still throws so a new image source fails loudly. Tests: 18 new cases including a positive control and 8 deco-vs-channel parity cases. 12 of the 18 fail against the pre-fix resolver, which is what proves they are load-bearing rather than vacuous. fixes #510	2026-07-26 20:54:00 +02:00
timothyandtimothy	0c063c23fb	harden(421,559): percent-encode access_token in IPTV URLs, redact from logs, no-store on tokened manifests (#574) ... Co-authored-by: Timothy <timothy.look@gmail.com> Co-committed-by: Timothy <timothy.look@gmail.com>	2026-07-23 16:30:59 +00:00
timothy	767f96802e	fix(392): apply schedule-level pad to Fill-With-Group items (reverse nav lost in DeepCopy)	2026-07-23 08:03:31 +02:00
timothyandClaude Opus 4.8	beab219a90	test(392): cover schedule pad through Flood/Duration/Multiple; make day-seam clamp precise ... Adds parameterized invariant tests (Schedule_clock_padded_offline_multimode) exercising schedule-level clock pad + offline advance across a 2-day window (two midnight crossings) through Flood, Duration, and Multiple — previously only PlayoutModeSchedulerOne had any coverage. Fixture uses sub-15-min content so each padded item occupies one :15 slot and Duration's fill-the-block contract tiles exactly (no off-boundary packing). Part 2 (precision): replaces the day-boundary anchor-clamp magnitude heuristic (overrun <= one pad interval on a padded schedule) with a precise signal — the last scheduler now reports the exact offline-pad target it advanced CurrentTime to (transient PlayoutSchedulerResult.ClockPadOfflineTarget, never persisted), and the clamp exempts only when CurrentTime equals that target exactly. A non-offline overrun (Duration/Flood/Multiple ending short of its natural end, a hard-stop, a tail advance) changes CurrentTime away from the target and still clamps, so persisted NextStart no longer shifts by up to an interval. No persisted-schema/migration change. Output byte-identical for all existing goldens. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 08:03:31 +02:00
timothy	7efe38dd04	feat(392): honor ProgramSchedule.PadToNearestMinute in the Classic builder	2026-07-23 08:03:31 +02:00
timothyandClaude Opus 4.8	f54c9ae195	refactor(395): dedup Scripted≡YAML enumerator construction into ContentEnumeratorBuilder ... Extract the byte-identical PlaybackOrder -> IMediaCollectionEnumerator switch shared by SchedulingEngine.EnumeratorForContent (Scripted) and EnumeratorCache.GetEnumeratorForContent (Sequential/YAML) into one static per-family seam, mirroring #380's ShuffleSourceBuilder. Each engine keeps its own "not supported" warning on the None branch, so the per-engine message is unchanged. Adds ContentEnumeratorBuilderTests pinning the block-shuffle-not-classic trap and the unsupported-order -> None (#70) contract across all 8 unsupported orders. Corrects the testing.scripted-playout-golden-deferred decision record: Scripted's external-process + HTTP pipeline is integration-only (deferred to #563), but the in-process SchedulingEngine it drives IS unit-testable (ScriptedScheduleController is a 1:1 pass-through) -- the earlier "un-golden-able by construction" framing conflated transport with engine. docs/testing.md reframed to match. [decisions-edit] fixes #395 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 20:21:52 +02:00
timothyandClaude Opus 4.8	80a9824a4e	test(381): golden coverage for Sequential (YAML) playout builder; document Scripted deferral ... Extends the #163 PlayoutBuildGoldenTests in-memory net to the Sequential (YAML) builder: a committed fixture (Goldens/Fixtures/sequential-schedule.yml) with two `count: 2` instructions over one chronological collection, built via SequentialPlayoutBuilder over the pinned window. The count/all/duration handlers do UTC-only arithmetic off the caller-supplied start, so the case is TZ-independent (passes, not skips, under a non-UTC TZ) and needs no Assume guard. Non-vacuity: a fixture count tweak flips the golden + the contiguity assertion. Scripted is deliberately excluded from the golden net — ScriptedPlayoutBuilder shells out via Cli.Wrap to an external process that drives SchedulingEngine over HTTP, which no in-memory golden can characterize. Recorded as the Done-when "documented decision" arm in docs/decisions.md (testing.scripted-playout-golden-deferred) + docs/testing.md; the scripted integration harness is tracked as follow-up #563. fixes #381 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 19:18:12 +02:00
timothyandClaude Opus 4.8	1ce5743bc1	fix(539): WorkAheadSlots.Release clamps before decrementing, reports unbalance in-band ... Three Low findings from the #536 clamp re-review, unreachable today (one guarded release site) but filed against the day a second release site is added. - §1: Release() now reads the count and CAS-decrements only when current > 0, so it never publishes a negative count even transiently. The prior decrement-first-then-clamp shape dipped to -1, which a concurrent TryAcquire could read as phantom room and over-admit at the limit (re-opening the #529 QSV pool exhaustion). It records the unbalanced release synchronously on the offending thread rather than blaming a later innocent release. - §3: Release() returns bool; HlsSessionWorker logs a warning on the false (unbalanced) return — the one in-band signal a future second release site would need. WorkAheadSlots stays logger-free by design. - §2: UnbalancedReleases doc-comment corrected — it can under-count (an over-release while count > 0 cancels a coexisting leak and goes unrecorded); no false positives, but zero does not prove correctness. Test: Release_Unbalanced_NeverPublishesNegativeCount (2M unbalanced releases vs 4 count-samplers) with a documented, verified negative control (reverting to the decrement-first body makes readers observe the transient -1). Adds a decisions.md entry (ffmpeg.work-ahead-slot-release-never-negative). fixes #539 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 20:59:32 +02:00
timothy	5db0836d41	fix(536): clamp an unbalanced work-ahead release instead of going negative ... Pre-push adversarial review, Low finding. The pool is process-wide and lives for the life of the app, so a `Release()` not matched by a successful `TryAcquire` would drive the count to -1 permanently: with a limit of 1 that silently admits two unthrottled transcodes forever, which is exactly the #529 QSV pool exhaustion with nothing in the logs to find it by. Clamp at zero and record the breakage in `UnbalancedReleases` rather than throwing — the sole caller releases from a `finally`, where a throw would swallow the real exception. The hammer tests now also assert `UnbalancedReleases == 0`, so the clamp cannot mask drift it was added to survive. Also moves the #536 index line to the end of the in-file decisions index (it was inserted in the 2026-07-11 block while its body appends at the end) — review nit, anchors were already correct. refs #536	2026-07-21 18:23:12 +02:00
timothy	c0d3dab190	fix(536): enforce workAheadSegmenterLimit with an atomic slot claim [decisions-edit] ... The slot check and its increment straddled an await: `Run` compared `Volatile.Read(ref _workAheadCount)` against a DB-backed limit, and the increment happened later inside `Transcode`. Every simultaneous tune-in therefore observed `0 < limit` and started unthrottled — three concurrent tunes on prod with a limit of 1 all ran with no `-readrate`. `Interlocked` on the write side alone buys nothing when the read side is a separate, earlier load (same class as #231/#250). Extract the counter into a `WorkAheadSlots` pool whose `TryAcquire(limit)` claims via compare-exchange, so the count never even transiently exceeds the limit that the QSV hardware-frame pool sizing (#529) is derived from. `Run` claims the slot and passes ownership in; `Transcode(bool ownsWorkAheadSlot, ...)` derives `realtime` from it and releases it in its existing `finally`, keeping acquire/release one-for-one. Acquisition stays in the caller because `Run` sets `_state` from the outcome and `Transcode` reads that state on entry to pick the item start time. Tests hammer 8 threads x 20k rounds (a single Barrier round does not collide on this hardware); the documented negative control reinstates the check-then-act body and produces 15912 over-claiming rounds of 20000. Also annotates the #350 decision record, whose "every concurrent tune-in falls back to the throttled path" bullet described the intent rather than the behaviour. fixes #536	2026-07-21 18:16:13 +02:00
timothy	36375157ad	feat(525): render path no longer fetches a URL logo; degrades to no bug	2026-07-21 13:13:21 +02:00
timothy	7ee436241a	refactor(525): extract RemoteImageDecodeBudget from ImageElementBase	2026-07-21 13:13:21 +02:00
timothy	66448e1abf	fix(502): correct the deco-scoping claim, extract + test the routing guard ... Adversarial review found a documentation defect, not a code one: both docs/decisions.md and the WatermarkSelector comment asserted the deco path was unaffected by this change. That is true of the *resolution* half and false of the *routing* half. SelectWatermarks puts deco-derived options into the same list the routing guard filters, so a deco watermark whose resolved path is a URL is rerouted to the graphics engine too — including the generated-initials localhost URL, which only the deco path still emits and which plausibly rendered through ffmpeg before. That reroute is intended (routing by what the path is beats routing by provenance, which would drift), so the fix is to say so accurately rather than to narrow the guard. Also records the accepted per-frame cost asymmetry the entry previously argued on correctness grounds alone. The guard is extracted as CanUseFFmpegNativeWatermark so it can be tested directly — review's highest-value gap was that the half of the fix which decides whether pixels appear had no automated coverage, only the one-off live E2E. Nine cases pin it, including the localhost-fallback reroute. Both deferrals now point at real issues instead of an unverifiable "tracked separately": #510 (deco vs precedence-level missing-logo policy) and #511 (remote-fetch hardening — timeout, size cap, redirects, pooling, caching, SSRF). Also pins scheme-case insensitivity in the selector.	2026-07-20 23:00:27 +02:00
timothy	f9bd245158	fix(502): render the on-screen bug for external-URL channel logos ... A channel whose logo is an external URL never rendered a watermark, even with an ImageSource=ChannelLogo watermark attached. WatermarkSelector resolved the URL correctly and then existence-checked it on the filesystem — File.Exists("https://…") is always false — so all three precedence levels (playout item, channel, global) logged "Channel logo no longer exists" and returned None. The channel editor advertises the URL as winning over an uploaded logo, which was true for the guide listing and silently false for the bug. External artwork passes through rather than being downloaded into the image cache: that is already the convention everywhere else (M3U, XMLTV, SPA JSON all emit the raw URL), no fetch->SaveArtworkToCache glue exists, and the render path does not need it — ImageElementBase.LoadImage already fetches an http(s) path with HttpClient and decodes it for real pixel dimensions. A remote-URL watermark is therefore forced onto the graphics engine instead of the ffmpeg-native shortcut, which would otherwise hand the URL to ffprobe and ffmpeg as a bare -i argument, putting an unbounded network fetch inside stream startup. The three gated precedence levels now share one ChannelLogoWatermarkOptions helper — the triplicated block is what let the defect exist three times over. Scope held narrow: the generated-initials localhost fallback (#1) stays disabled behind an explicit comment and a scope-guard test, and the deco path keeps its own long-standing unchecked policy. Verified by live-E2E against a real channel playout with an external-URL logo: origin/main renders 0 logo pixels and logs the "no longer exists" warning verbatim; this branch renders the logo in the expected region. Whitespace-only reformatting in FFmpegLibraryProcessService.cs is the fix-as-you-touch format gate on pre-existing violations, plus a BOM strip. fixes #502	2026-07-20 23:00:27 +02:00
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
timothyandClaude Opus 4.8	1d95cbfee6	fix(403): accurate Classic fallback message + engine-coverage tripwire ... Review follow-ups (cold review of PR #457): - Marathon can reach PlayoutBuilder's default arm via `goto default` when its enumerator can't be built; the new warning claimed "Marathon is not supported by classic scheduling", which is false. Distinguish supported-but-failed-to-build (logs "could not build") from genuinely unsupported using PlaybackOrderSupport, which also makes Classic a runtime consumer of the matrix. - PlaybackOrderSupportTests now asserts every SchedulingEngineKind has a matrix entry, so a new engine kind fails the test instead of throwing KeyNotFoundException at runtime. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 18:32:14 +02:00
timothyandClaude Opus 4.8	0f34c86afa	feat(403): make unsupported PlaybackOrder loud at build time + tripwire ... Adding a new PlaybackOrder was unsafe by construction: three build-time dispatch sites turned an unknown value into an enumerator silently. Classic substituted RandomizedMediaCollectionEnumerator (the // TODO default arm), PlaylistEnumerator had no default arm so the item was dropped, and BlockPlayoutBuilder's allow-list continue skipped it. (#70 already made YAML/Scripted log a warning and MultiCollectionGroup throws.) - each silent site now logs a Warning naming the order + engine + the fallback taken; the fallback itself is preserved so a live channel never goes dark on one misconfigured item and scheduler goldens do not move. - PlaylistEnumerator.Create gained an optional Option<ILogger> (it was static with no logger -- why the drop was unreportable); loggered callers pass it. - BlockPlayoutBuilder gained an explicit Random arm (it previously reached an enumerator only via the coincidental _ => fallback) and a loud defensive fallback. - new PlaybackOrderSupport matrix (per SchedulingEngineKind) + tripwire PlaybackOrderSupportTests: Supported ∪ Unsupported must partition the enum for every engine, so a new order fails the test until classified. BlockPlayoutBuilder consumes the matrix for its allow-list. - write-path rejection left unchanged (#70 closed the persistence hole; the perimeter has been wrong three times per decisions.md); reverse _ => None mappings reviewed and deferred (different axis; making them loud would warn on legit enumerator types). docs/decisions.md updated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 18:23:21 +02:00
timothyandClaude Opus 4.8	6c8c7feeba	feat(350): instrument HLS cold-start latency (phase split + feature flags) ... Adds one Information-level structured log per HLS tune-in cold-start so the real driver breakdown can be measured on prod before optimizing the transcode pipeline (measure-before-optimize). Log-only; no transcode behavior change. - WaitForPlaylistSegments returns a PlaylistSegmentsResult: Phase A (process startup -> playlist exists) vs Phase B (segment fill), segments reached, deadline-expired. - StartFFmpegSessionHandler emits one summary: total = setup + startup + fill, plus cleanly-detectable feature flags (subtitle burn-in, hwaccel family). - ColdStartFeatures: pure, unit-tested args->features helper (14 cases). Watermark / HDR->SDR / image-subtitle burn-in are deliberately not flagged (all reduce to overlay= in the args, indistinguishable); the full ffmpeg arguments remain available at Debug. Refs #350 (instrumentation slice; optimization deferred pending real data). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 15:30:56 +02:00
timothy	ffa8e5a000	Merge pull request 'fix(376): XML-escape access_token value in XMLTV guide output' (#419) from fix/376-xmltv-token-escape into main	2026-07-17 17:34:24 +00:00
timothyandClaude Opus 4.8	bf15677dc6	fix(376): XML-escape access_token value in XMLTV guide output ... `GetChannelGuideHandler` interpolated `request.AccessToken` (HTTP-request- derived, from `?access_token=`) raw into the pre-built XMLTV cache fragments. A token containing `&`, `<`, `>`, or `"` would emit invalid XML and malform the entire guide. Escape it with `SecurityElement.Escape`, consistent with how #340 escaped `{RequestBase}`. The M3U path (`ChannelPlaylist.ToM3U`) also interpolates the token but M3U is not XML, so escaping there is neither needed nor correct — left unchanged. Regression test `Guide_xml_escapes_access_token` drives the real handler with a token containing all four XML-special chars and asserts the output is escaped (sibling to the #340 `Guide_xml_escapes_advertised_base_url` test). Verified non-vacuous: it fails with the escape reverted. fixes #376 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 19:04:42 +02:00
3 people	7446ce0293	test(70): classic-weighted golden — weight beats collection size end-to-end ... The unit tests pin the enumerator's sequence in isolation; this pins that the real PlayoutBuilder actually distributes by weight, through the whole chain: MultiCollection -> MediaCollectionRepository -> CollectionWithItems.Weight -> ShuffleSourceBuilder -> WeightedShuffleCollectionEnumerator -> PlayoutItems. The fixture is deliberately lopsided: the HEAVY source (weight 3) is the SMALL collection (2 items) and the LIGHT source (weight 1) is the LARGE one (4). Over the pinned 2-day window that yields 81 : 27 = exactly 3.00 : 1 — the smaller collection taking the larger share, which is the entire point of the feature and is not reachable by any existing order: Shuffle is size-proportional (~2:4 here) and ShuffleInOrder plays every item exactly once per cycle. Longest consecutive same-source run is 3, so it interleaves smoothly rather than draining blocks. Same determinism contract as Classic_shuffle: pinned Playout.Seed + Continue mode (Reset randomizes the seed). Channel number/GUID 5 — every golden fixture shares one in-memory DB, so those must be globally unique. The net is armed, not decorative: with the golden absent the test fails (missing golden is a hard failure by design), and regenerating added only classic-weighted — the three existing goldens are byte-identical, so nothing was silently re-baselined. Core.Tests 566 passed, 0 failed. Refs #70 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 17:00:46 +00:00
3 people	c0da414a4c	fix(70): close the review blockers — third playlist writer, weight bounds, overflow ... Adversarial review of PR #402 returned BLOCKED. It could not break the WRR math or the stateless-restore claim (it probed restore across wraps at indices 12/13/20/37 — all held, and the clamp preserves a 1000:1 ratio exactly). What it broke was the perimeter. B1 — the validation gate had a hole, so the silent-drop bug shipped. CreateChannelFromLineup is a THIRD writer of PlaylistItem.PlaybackOrder; its own guard only covered MultiCollection entries, so a 2+ entry lineup of plain collections persisted WeightedShuffle straight through to PlaylistEnumerator's null-drop. My decisions.md claim that "the silent sites never see it" was false as written — corrected in place, with the lesson recorded: grep every writer of the field, the non-obvious composite handler is the one that gets missed. The Add*ToPlaylist handlers are safe only because they hardcode their order. B2 — Weight had no validation at all, and create/update disagreed on the same input. EF's HasDefaultValue(1) substitutes 1 for a 0 on INSERT (0 reads as "not set") but an UPDATE writes the 0 through — and a 0-weight source was filtered out of the rotation, deleting it from the channel silently. Exactly the failure this order is careful to avoid everywhere else. Now bounded 1..1000 by a shared MultiCollectionItemWeight used by both paths so they cannot drift, and clamped again in the enumerator for rows that predate the gate. B3 — Sum(weights) is checked arithmetic, so two int.MaxValue weights threw OverflowException from inside a playout build. Reachable through the API precisely because of B2. The ceiling fixes both; the sum also widens to long. M1 the lineup mirror now allows WeightedShuffle for multi collections, matching the PlayoutModeMustBeValid change it claims to mirror. M3 ScheduleAsGroup is documented as deliberately unread by this order. L1 MinimumDuration is computed over every source instead of the current rotation — under the clamp a rotation is a strict subset and is rebuilt each wrap, so caching over it went stale. L2 the retry guard keys off the rotation, not the raw collection count. N1 the tautological default test is gone: it built entities in C#, so it asserted the property initializer, not the migration — it could not have failed. Replaced with clamp, overflow, and cross-wrap restore cases (the property the review proved but found unpinned). H1 the two follow-ups the PR body claimed were "filed" did not exist. Now filed: #403 (silent dispatch-fallback hardening) and #404 (SPA weight UI, blocked-by #388). Core.Tests 565 passed, ErsatzTV.Tests 1643 passed, 0 failed. Refs #70 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 17:00:46 +00:00
3 people	07cb8c0287	test(70): pin WeightedShuffle semantics; fix unbounded reshuffle retry on wrap ... Ten tests pin the distribution contract exactly rather than statistically, because the sequence IS the product decision: 3:1 emits A A B A (spread, not drained); equal weights air a 2-item source as often as a 20-item one; ties break to the earliest source; a defaulted weight behaves as fair-share (guarding the migration default); restoring at an index equals advancing to it (the stateless contract that lets CollectionEnumeratorState carry this order). Fixes a hang found by the non-vacuity control. When a rotation wraps, MoveNext retried the rebuild to avoid an immediate repeat. ShuffleInOrder can do that unbounded because its reshuffle randomizes the lead item — but this order's lead is decided by weight, so the heaviest source always leads, and when it holds a single item the lead never changes and the retry never terminates. Two single-item collections with unequal weights would wedge the playout build. The retry is now bounded: avoiding a back-to-back repeat is a nicety, not terminating is not. Regression test walks several wraps under a timeout. Non-vacuity proven per repo lore: inverting the real WRR pick (max -> min, never if(true), which trips CS0219 under warnings-as-errors and silently serves a stale dll to --no-build) failed 5 of 10 tests on a clean build (0 errors, so not a stale-dll false pass). Reverted; 10/10 green. Refs #70 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 17:00:46 +00:00
timothyandClaude Opus 4.8	f5cc27e902	test(380): avoid channel-number collision with #77 golden fixture ... Post-rebase onto main (which merged #77's Classic_clock_padded golden): both fixtures seed the shared in-memory DB and independently picked Channel Number "3"/GUID ...0003, tripping a UNIQUE constraint. Move the shuffle fixture to "4"/...0004. Golden output is unchanged (it snapshots times/titles; shuffle determinism comes from playout.Seed). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-17 08:50:36 +02:00
timothyandClaude Opus 4.8	8e7cba4c44	test(380): pin the keepMultiPartEpisodesTogether=true shuffle-source branch ... Addresses the one substantive nit from the cold adversarial review of PR #391: the true branch of ShuffleSourceBuilder.GetGroupedMediaItemsForShuffle (routing through MultiPartEpisodeGrouper) had no direct regression net — the goldens and existing unit tests all use false. Add a test that observably distinguishes the branches: four episodes where two are a "(1)"/"(2)" multi-part pair collapse to 3 groups under keepMultiPartEpisodesTogether=true vs 4 groups under false. Test-only; no production change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-17 08:48:05 +02:00
timothyandClaude Opus 4.8	764cd3c31b	feat(380): extract shuffle-source construction to ShuffleSourceBuilder ... Eliminate the one cross-engine reach-in in the scheduler: PlaylistEnumerator called PlayoutBuilder.GetGroupedMediaItemsForShuffle / GetCollectionItemsForShuffleInOrder as statics (one engine reaching into another engine's class). Move both helpers verbatim to a new public static ShuffleSourceBuilder in ErsatzTV.Core/Scheduling (sibling to the also-static MultiCollectionGrouper / MultiPartEpisodeGrouper; deps passed as parameters, not DI). Classic (PlayoutBuilder) and Playlist (PlaylistEnumerator) now share this one place to build shuffle sources. One intentional signature change: GetGroupedMediaItemsForShuffle takes (bool keepMultiPartEpisodesTogether, bool treatCollectionsAsShows) instead of a ProgramSchedule (verified those are the only two properties it read). This deletes PlaylistEnumerator's fake `new ProgramSchedule { KeepMultiPartEpisodesTogether = false }` (its TODO becomes an honest false, false) and gives callers without a ProgramSchedule (#176, #70) a schedule-entity-free entry point. Scope is deliberately (a)-only: engine separation preserved, no god-factory. Block stays its own family; the Scripted/YAML construction duplication is a separate follow-up gated on #381. See docs/decisions.md 2026-07-17. Behavior-preserving: the characterization net added in the previous commit (classic-shuffle golden byte-identical, PlaylistEnumerator reach-in sequence unchanged) plus new direct ShuffleSourceBuilder unit tests (multi-collection vs fake-multi-collection lookup; multi-part grouping on/off) all green. Full Core.Tests: 546 passed. PlayoutBuilder.cs also de-BOM'd + whitespace-normalized per the fix-as-you-touch convention (#311). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-17 08:48:05 +02:00
timothyandClaude Opus 4.8	604ea96c9f	test(380): characterize shuffle paths before enumerator-seam extraction ... The #163 golden net (PlayoutBuildGoldenTests) only pins PlaybackOrder.Chronological on Classic + Block. The paths #380 refactors — the two PlayoutBuilder shuffle-source statics and PlaylistEnumerator's cross-engine reach-in into them — had zero coverage, so "goldens green before & after" would be a false safety signal. Extend the net to exactly the moved paths: - PlayoutBuildGoldenTests.Classic_shuffle: Classic builder + PlaybackOrder.Shuffle, pinned playout.Seed via Continue mode (Reset randomizes the seed) so the shuffle is deterministic and TZ-independent. Exercises GetGroupedMediaItemsForShuffle + the ShuffledMediaCollectionEnumerator wiring. - PlaylistEnumeratorTests.ReachIn_Shuffle_And_ShuffleInOrder_Items_Are_Characterized: a playlist with a Shuffle item and a ShuffleInOrder item, pinned seed, asserting the emitted id sequence. Covers both PlaylistEnumerator.Create reach-in call sites (:174 GetGroupedMediaItemsForShuffle, :185 GetCollectionItemsForShuffleInOrder) that the extraction rewires. No production changes. Verified deterministic across repeated runs and under TZ=UTC / Asia/Kolkata. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-17 08:46:24 +02:00
timothyandClaude Opus 4.8	17746c442e	test(77): address cold-review nits — TZ-invariant guard comment + DecoDefault ... Follow-up to the MERGEABLE cold review: - Golden: document that TZ-independence relies on PadToNearestMinute=15 dividing every IANA offset; warn against regenerating with a non-15 divisor. - decisions.md: include DecoDefault in the ProjectFlood coalesce list. [decisions-edit] corrects a factual omission in the same-PR entry added this session. Refs #77 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 01:22:07 +02:00
timothyandClaude Opus 4.8	7e6b9d2747	test(77): characterize clock-boundary schedule padding; docs ... #77's core (pad/snap schedules to :00/:15/:30 via filler) already exists — FillerMode.Pad + PadToNearestMinute (Classic), pad_to_next/pad_until (Sequential); Block is inherently time-anchored. No production code change; this locks the behaviour end-to-end and documents that it exists. - PlayoutBuildGoldenTests.Classic_clock_padded: a PostRoll FillerMode.Pad(15) preset through the real PlayoutBuilder snaps content to :15 (golden + explicit quarter-hour assertion). Splits Verify -> CompareGolden for reuse. - ChannelGuideProjectorClockPadTests: the guide projection coalesces trailing filler so programmes STOP on the padded boundary (XMLTV half). - docs: decisions.md (2026-07-17 entry), domain-model.md (clock-boundary row), testing.md (test map + count 540->542). Deferred (UI, blocked on #388): one-click per-channel/schedule clock-align toggle + 60-min increment option. Refs #77 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 01:22:07 +02:00
timothyandClaude Opus 4.8	1131ecacfb	test(163): apply review nits — instant-accurate Block TZ guard + determinism notes ... Follow-up to the cold adversarial review of PR #382 (MERGEABLE-WITH-NITS): - Block TZ guard: BaseUtcOffset -> GetUtcOffset(Start). BaseUtcOffset is zero year-round for DST zones like Europe/London, so it would pass in a summer-dated fixture where London != UTC; GetUtcOffset pins the actual build instant and is correct regardless of fixture date. (Safe today — mid-Jan fixture — but removes the latent fixture-date dependency the reviewer flagged.) - Document the determinism invariants the fixture relies on: golden captures raw builder output (pre-trim AddedItems), Classic is TZ-independent for the captured fields (no guard needed), and ResetPlayout's random Seed can't perturb the Chronological fixture (RandomStartPoint/ShuffleScheduleItems false, distinct release dates). Re-verified: TZ=UTC both goldens pass; TZ=America/New_York Block skips, Classic passes; no golden drift. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 23:47:54 +02:00
timothyandClaude Opus 4.8	dc5d889ccb	test(163): golden characterization tests for playout building (Classic + Block) ... Add ErsatzTV.Core.Tests/Scheduling/Goldens/PlayoutBuildGoldenTests.cs — a golden-file net that snapshots the PlayoutItems each builder produces over a pinned build window; the scheduling counterpart to the M3U (#11) / XMLTV (#28) goldens. This is the regression net that de-risks the scheduling-refactor chain (#380 -> #70/#71/#176). Coverage this slice: - Classic (PlaybackOrder.Chronological) - Block (TimeZoneInfo.Local-guarded to UTC via Assume: runs in CI, skips gracefully under a non-UTC TZ; a real TZ seam is #380's scope) Determinism: the builders read no wall clock (time enters only via the caller-supplied start), so a pinned start is fully deterministic. Snapshots the raw UTC Start/Finish, not the *Offset properties (which .ToLocalTime()). Regen via ETV_UPDATE_PLAYOUT_GOLDENS (deliberately separate from ETV_UPDATE_GOLDENS). Both goldens proven non-vacuous. Sequential (YAML) + Scripted goldens tracked as a follow-up in #381. Docs: docs/testing.md updated (third golden net + env var + Block TZ guard). fixes #163 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 23:41:33 +02:00
timothyandClaude Opus 4.8	27d01db265	fix(iptv): XML-escape advertised base URL in XMLTV guide output (#340 review) ... Independent review found that AdvertisedBaseUrl.TryParse accepts a path prefix containing '&' (a legal URL-path char kept out of uri.Query), but GetChannelGuideHandler substituted {RequestBase} raw into pre-built XML written unescaped — so a configured base like https://host/a&b emitted a bare '&', malforming the entire XMLTV guide (clients reject the document). Escape the substituted base with SecurityElement.Escape before the raw replace, mirroring how {AccessTokenUri} is already pre-escaped (&amp;). No-op for normal URLs (goldens unchanged); M3U output is untouched (M3U isn't XML). Adds a regression test asserting '&' → '&amp;' in the guide. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 21:08:42 +02:00
timothyandClaude Opus 4.8	3bc8192d3b	feat(iptv): add configurable advertised base URL for M3U/XMLTV (fixes #340) ... ErsatzTV built every absolute M3U/XMLTV URL from the incoming request's Scheme/Host/PathBase, so a client fetching via a host that downstream consumers can't resolve (e.g. Dispatcharr over Docker DNS → Kodi) baked that internal host into programme-image/stream URLs. Add an optional advertised IPTV base URL, backed by the existing ConfigElement key/value store (key `iptv.base_url`, no EF migration): - Central pure Core helper `AdvertisedBaseUrl` (TryParse/Resolve): validates absolute http(s), no credentials/query/fragment, preserves port + path prefix, normalizes trailing slash. Blank/invalid falls back to the request-derived values, so unset output is byte-identical. - Resolved inside `GetChannelPlaylistHandler` (M3U guide/logo/stream) and `GetChannelGuideHandler` (both XMLTV {RequestBase} sites) — controllers stay thin, golden tests untouched. - New `iptv` settings group: GET/PUT /api/v1/settings/iptv (blank clears, malformed → 422) + a new IPTV section on the SPA Settings screen. - Scoped to M3U + XMLTV; HDHomeRun deliberately out of scope. Distinct from ETV_BASE_URL (which only sets ASP.NET PathBase). Tests: AdvertisedBaseUrl unit tests (override/fallback/port/path/invalid), handler override tests for both generators, settings controller + handler tests, SPA client + screen tests. Docs: m3u-xmltv, decisions, domain-model, regenerated OpenAPI v1.json + v1.d.ts + endpoint-index. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 21:08:42 +02:00
timothyandClaude Opus 4.8	a886fd2824	ci(coverage): make ReportGenerator install idempotent + pinned (review follow-up) ... Cold-review should-fix on PR #370: `dotnet tool install` errors under set -e if the tool is already present (retried step / cached runner image), which would silently degrade the continue-on-error summary step to a no-op. Use `dotnet tool update` (install-or-update) pinned to 5.5.10 for reproducible output. Also order coverlet.collector after CliWrap to keep the ItemGroup alphabetical (nit). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 18:49:28 +02:00
timothyandClaude Opus 4.8	2090f7865c	ci(coverage): collect code coverage and publish a summary (refs #15) ... #15 scope item 4 ("collect with coverlet and publish a summary; decide on a floor later"). coverlet.collector was already referenced by four of the six test projects but the CI Test step never passed --collect and nothing summarized the result. - Add coverlet.collector to ErsatzTV.Core.Tests and ErsatzTV.Tests so coverage is uniform across all *.Tests projects. - CI Test step now runs --collect:"XPlat Code Coverage" --results-directory ./coverage, then a best-effort Coverage summary step merges the per-project Cobertura reports with ReportGenerator (TextSummary to the log, MarkdownSummaryGithub to the job step summary). No floor is enforced yet; continue-on-error keeps it purely informational. - gitignore /coverage/; document the step in docs/ci-cd.md (test job). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 18:45:32 +02:00