3099 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
timothyandtimothy	56dff2c49f	docs(489): spec + implementation plan for Jellyfin mixed-content libraries (#490) ... Design spec and bite-sized TDD implementation plan for #489, whose implementation landed in #493. Docs-only. Kept as the record of how the design was reached: that Jellyfin classifies mixed-library items server-side via includeItemTypes (so no inference is needed), that MediaItem is TPT keyed on LibraryPathId (so no migration is needed), that MediaKind is dispatch + presentation only, and why the feature is deliberately scoped to Jellyfin rather than local libraries. Also records the open risk the plan carried -- the music-video scanner's untraced reconciliation -- which #494 subsequently answered. Refs #489 Co-authored-by: Timothy <timothy.look@gmail.com> Co-committed-by: Timothy <timothy.look@gmail.com>	2026-07-20 16:36:02 +00:00
timothyandtimothy	2cf90fb44f	feat(489): support Jellyfin mixed-content libraries (#493) ... Jellyfin libraries typed `mixed` were dropped by JellyfinApiClient.Project's `_ => None` with no log line, so music and standup content could not be ingested without a local-library workaround that bypassed Jellyfin entirely. Adds LibraryMediaKind.Mixed, maps "mixed"/absent/blank CollectionType onto it, and gives SynchronizeJellyfinLibraryByIdHandler a Mixed arm composing the three existing per-kind scanners. Jellyfin classifies items server-side via includeItemTypes, so the passes see disjoint sets; reconciliation is type-scoped and cannot cross-delete. No new scanner and no DB migration -- MediaItem is TPT keyed on LibraryPathId, so heterogeneous contents were already legal. Segregation falls out of the model: a library is a place (one path <-> one Jellyfin library <-> one ErsatzTV library), so music/standup cannot leak into Movies or TV Shows. Also removes the silent-success `_ => Unit.Default` from both scanner dispatchers, which returned Right for an unhandled kind and stamped LastScan as though a scan had run, and rejects Mixed for local libraries at the API. Deliberately Jellyfin-only: local scanners share one video extension list and would claim each other's files, and LibraryFolder etags are keyed by LibraryPathId with no notion of kind. Verified by live E2E against a real Jellyfin, including the interaction with #494's reconciliation sweep. Four cold review rounds, all MERGEABLE. fixes #489 Co-authored-by: Timothy <timothy.look@gmail.com> Co-committed-by: Timothy <timothy.look@gmail.com>	2026-07-20 16:34:51 +00:00
timothyandtimothy	5b0d8b5d09	fix(494): reconcile removed music videos in Jellyfin scanner (#495) ... fix(494): reconcile removed music videos in Jellyfin scanner (#495) JellyfinMusicVideoLibraryScanner did add/update only, so a music video or artist deleted on the Jellyfin side lingered forever. Add a library-scoped trash sweep (TrashMissingMusicVideos) gated by the #477 empty-fetch guard. fixes #494 Co-authored-by: Timothy <timothy.look@gmail.com> Co-committed-by: Timothy <timothy.look@gmail.com>	2026-07-20 15:22:15 +00:00
timothy	a696f06d57	Merge pull request 'fix(488): resolve LibraryFolder from DB so Jellyfin music-video scans stop crashing' (#492) from fix/488-getoraddfolder-null-libraryfolders into main	2026-07-20 14:09:00 +00:00
timothyandClaude Opus 4.8	d3db2f6af1	fix(488): resolve LibraryFolder from DB so Jellyfin music-video scans stop NRE'ing ... GetOrAddFolder read libraryPath.LibraryFolders, a navigation collection only eager-loaded on the local scan path (via GetLibrary). The Jellyfin remote sync path takes its LibraryPath off the JellyfinLibrary entity, where LibraryFolders is null, so .Filter(null) threw ArgumentNullException('source') on the first item of every Jellyfin music-video scan — a feature that had therefore never run in prod, CI, or locally. Look the folder up from the DB by (LibraryPathId, Path) instead, removing the implicit eager-load contract entirely (correct for all nine callers) and documenting it on ILibraryRepository. null != empty is preserved so a re-scan does not insert duplicate LibraryFolder rows. No new hot-path cost: local scanners already query GetParentFolderId per folder just before this call. Tests: - LibraryRepositoryTests: GetOrAddFolder with a null LibraryFolders (the exact remote-path shape) creates the folder, is idempotent on re-scan, and persists a supplied ParentId. - JellyfinMusicVideoLibraryScannerTests: an end-to-end scan of one synthetic music video, wiring the REAL LibraryRepository/ArtistRepository/ MusicVideoRepository against in-memory SQLite (the existing MediaServer* scanner tests mock every repo, which is why the bug escaped), asserts the scan completes and creates Artist + MusicVideo rows with a real LibraryFolder. Both proven non-vacuous against the reverted fix (each reproduces the issue's ArgumentNullException). decisions.md entry added. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 01:16:16 +02:00
timothy	3c5f4e867a	Merge pull request 'fix(480): probe external-JSON remote-stream URLs before ffmpeg' (#486) from fix/480-external-json-probe into main	2026-07-19 22:37:29 +00:00
timothyandClaude Opus 4.8	4a9502cbb5	fix(480): probe external-JSON remote-stream URLs before handing them to ffmpeg ... External-JSON playout channels build their own /media/plex/{server}/{plexFile} URL in ExternalJsonPlayoutItemProvider.StreamRemotely and the handler assigns it without routing through ValidatePlayoutItemPath, so the #473 class survived here: a media item gone from the server 404s under ffmpeg (exit 8) and the same dead item is re-selected for its whole slot. Route StreamRemotely through the same IRemoteStreamProber seam #473/PR #479 added for the generated-playout path. Probe runs before the Plex metadata round-trip (the URL needs only server.Id + plexFile), so a gone item skips it. An unavailable stream returns PlayoutItemNotAvailableFromMediaServer, which the handler already maps to a real-error card. The fail-open policy (redirected-404 only) lives inside IRemoteStreamProber, so this second call site duplicates only the decision to probe. Tests: ExternalJsonPlayoutItemProviderTests pins both directions; proven non-vacuous by neutralizing the probe. docs/decisions.md gets a #480 entry closing the #473 scope gap (append-only: the old #473 entry is cross-referenced, not edited). fixes #480 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 00:17:15 +02:00
timothy	ab25658643	Merge pull request 'feat(472): sub-split the HLS cold-start startup phase' (#482) from feat/472-startup-subsplit into main	2026-07-19 21:59:22 +00:00
timothy	55be64bd77	Merge pull request 'fix(477): guard media-server library sweeps against successful-but-empty fetches' (#483) from fix/477-scanner-antinuke-guard into main	2026-07-19 21:53:37 +00: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
timothyandClaude Opus 4.8	aa32fd78dd	fix(477): guard media-server library sweeps against successful-but-empty fetches ... A successful fetch returning zero items made existing.Except([]) flag the ENTIRE library FileNotFound in one scan — feeding EmptyTrashHandler's permanent delete and emptying every affected collection (dead channels). Add a shared MediaServerReconciliationGuard that skips (and logs a Warning) the sweep when incoming==0 while items exist, wired into the three library-level sweeps (Television shows / Movie / OtherVideo). An empty incoming set is indistinguishable at scan time from a mid-restore / emptied-upstream error (both report a zero total), so this deliberately overrides #476's degenerate "last item removed => empty incoming => flag" case. #476's cascade still fires for partial deletions (survivors present); its characterization test moves from an empty incoming to a survivor+removed partial-deletion case. Tests: policy table (MediaServerReconciliationGuardTests) + per-scanner integration proving the wiring (empty incoming + non-empty existing flags/reindexes nothing). Proven non-vacuous by neutralizing the guard. Nested TV season/episode sweeps left unguarded (bounded blast radius); ratio-threshold + projection-failure detection deferred to a follow-up. docs/decisions.md updated. Fixes #477 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 23:28:27 +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
timothy	de11eb01b3	Merge pull request 'fix(473): probe media-server remote streams before handing the URL to ffmpeg' (#479) from fix/473-missing-media-resilience into main	2026-07-19 20:24:59 +00:00
timothy	0d70425572	Merge pull request 'fix(476): cascade FileNotFound from removed shows/seasons to descendants' (#481) from feat/476-cascade-filenotfound into main	2026-07-19 20:19:37 +00:00
timothyandClaude Opus 4.8	1eff0b39b7	fix(473): gate the cancellation filter on the caller's token ... Third review pass: MERGEABLE WITH NITS. Taking the one finding it asked for before merge, plus a doc nit. The cancellation filter added last commit had no token check, and it spans the whole Transcode body -- including every mediator send (ffprobe via CliWrap, media-server API calls, subtitle extraction, song-video generation). TaskCanceledException is also what HttpClient throws on its OWN timeout, so a real timeout in any of those was being downgraded from an ERROR with a stack trace to a routine "Terminating HLS session" Information line. Behaviour was unchanged (both arms return false) but the fault signal was lost, and this repo has been bitten before by "empty log != the event didn't happen". Now filters on cancellationToken.IsCancellationRequested, so only genuine caller cancellation is treated as a graceful teardown. Doc nit: the <exception> block said cancellation "is thrown"; it is only thrown when the token trips while the probe is in flight -- cancelling after it completes returns normally. Now says "may propagate". Declined the reviewer's optional suggestion to drain until a 0-return instead of reading exactly one byte: reading exactly one byte is what makes the guard safe BY CONSTRUCTION, since a server or proxy that answers 206 with a wider range than requested still cannot be drained unboundedly. 206-only was confirmed correct rather than extended to short 200s, since deciding "short" from Content-Length would reopen the unbounded path for a chunked or Content-Length-less response. Also records the operator's standing rule in the handoff lore: a lone `decisions.md append-only` red is a known infra flake -- do not investigate, rebase, amend or push to clear it; the operator reruns that job from the UI. I violated this earlier in this PR with a tidy-but-wrong "my entry is no longer at EOF" theory, and the rebase did not fix it -- the job went red again on a verified pure-append diff, which is the proof the red was never about the diff. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 22:02:15 +02:00
timothyandClaude Opus 4.8	61bd374494	fix(476): cascade FileNotFound from removed shows/seasons to descendants ... The media-server television scanner reconciles removed items at three levels via existing.Except(incoming), but the season and episode sweeps live inside the per-parent loops (ScanSeasons inside the show loop, ScanEpisodes inside the season loop). Those loops only iterate parents present in the incoming list, so a show (or season) that is gone from the media server is never visited and its descendants are never swept — they keep their last state. On Jellyfin/Emby that is RemoteOnly, which PlayoutBuilder does NOT skip even with PlayoutSkipMissingItems on, so every orphaned episode keeps getting scheduled as a guaranteed tune-in failure (the #473 reproduction; 717 stale prod rows across 10 removed shows). Fix: cascade the flag by parent MediaItem.Id. Two provider-agnostic repo helpers (Season.ShowId / Episode.SeasonId are on the base tables) flag descendants and the scanner drives them after each parent sweep — show → seasons → episodes, and season → episodes for the show-present case. Shared abstract base fixes Jellyfin/Plex/Emby at once; Movie/OtherVideo are flat and have no such gap. Tests: a Scanner.Tests case asserts the scanner cascades through the (substituted) repository (non-vacuous — fails if the cascade calls are removed), and Integration tests exercise the real cascade SQL against the schema, proving it flags only the targeted subtree and no-ops on empty input. fixes #476 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 21:49:33 +02:00
timothyandClaude Opus 4.8	dc5ceb5a14	fix(473): bound the drain, correct the interface contract, quiet graceful cancels ... Second review pass returned BLOCKED on two findings introduced by the first fix commit. Both were right. BLOCKER 1 — the drain added for "return the connection to the pool" was unbounded. `response.Content.ReadAsByteArrayAsync()` buffers the WHOLE body, and it ran for every non-404 response. A server that ignores `Range: bytes=0-0` answers 200 with the entire file, so this would download at line rate into a byte[] on the streaming hot path for up to the 2s timeout -- strictly worse than the aborted socket it replaced, and it defeated the ResponseHeadersRead the probe deliberately uses. Now the single byte is read only on 206 (where the server honoured the range and the body really is one byte); any other status aborts the socket, which is much the cheaper evil. Two tests pin both directions; verified non-vacuous (restoring the unbounded drain fails the 200-with-body test). BLOCKER 2 — IRemoteStreamProber's doc-comment still described pre-fix behaviour. I had told the reviewer it was updated; it was not -- only the implementation's <remarks> had been. It claimed `false` on any 404 (now only a redirected one) and that every other outcome returns `true` (caller cancellation throws). Both clauses corrected, and the throwing contract is now documented with <exception>. Also fixed the reviewer's own follow-on finding: the cancellation rethrow it asked for reached HlsSessionWorker's catch-all, which logs a channel-level ERROR with a stack trace. The graceful TaskCanceledException/OperationCanceledException handler at :662 wraps only the inner ffmpeg block, not the mediator sends, so every client disconnect on a remote-streaming channel would have produced a spurious ERROR -- in exactly the logs a #350 cold-start investigation reads. Added a cancellation filter on the outer try that logs Information instead. Nit: stale SeedAll doc-comment now mentions the emby case. Deferred, per reviewer's explicit agreement: Plex-branch handler coverage (follow-up), and HEAD-with-GET-fallback. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 21:47:50 +02:00
timothyandClaude Opus 4.8	a10c0325eb	fix(473): compare parsed Uris in the redirect check ... Defense in depth on the redirect detector: Uri.Equals compares normalized components, so an escaping/casing difference can't be mistaken for a redirect and fail CLOSED -- the exact failure the check exists to prevent. A plex key can contain spaces or unicode. Honest note: this is NOT a fix for an observed bug. I wrote a test claiming to pin it, then ran the negative control and the test passed against the string comparison too -- Uri.ToString() unescapes, so both forms agree for our machine-generated URLs. The test was vacuous as written. It is kept, retitled and re-commented to describe what it actually guards (an un-redirected 404 on an escaping-sensitive url fails open), and the code comment says plainly that this is defense in depth rather than a repair. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 21:42:21 +02:00
timothyandClaude Opus 4.8	bad19f8d26	fix(473): review fixes — only a redirected 404 fails closed ... Adversarial review of PR #479 found the stated fail-open contract was not what the code measured, plus four smaller gaps. All fixed here as a follow-up commit (no amend/force-push). High — a 404 from ErsatzTV's OWN endpoint was treated as "media gone". /media/{provider}/... is served by InternalController, which returns NotFound when the media source is unconfigured or momentarily missing (a media-source edit that deletes+reinserts connections, a restore, a partially-configured server). Probing for "any 404" therefore failed CLOSED for every item on that source -- exactly the case the fail-open contract exists to prevent. A media-server 404 always arrives after a redirect, so an un-redirected 404 is now treated as available. Medium — the new switch label was untested and its benefit overstated. maybeDuration/finish are computed before the switch, so `default:` already sized the error card to the next playout item; the label only changes the caption. The handler test asserted call counts only, so deleting the label still passed. It now asserts the error message, and removing the label fails the test (verified). Medium — Plex/Emby branches changed but had no coverage. Added an Emby handler test asserting the probe is called with the emby URL. Low — caller cancellation was swallowed and pinned as desired behaviour. A shutdown / client disconnect is a genuine signal, not a probe failure; it now propagates, and only the probe's own 2s timeout fails open. Low — the response stream was disposed unread, aborting the connection instead of returning it to the pool. The one requested byte is drained. Nit — fully-qualified RangeHeaderValue replaced with a using. docs/decisions.md corrected where it overstated: the switch label's role, the "fixes the class for all three media servers" claim (external-JSON channels bypass ValidatePlayoutItemPath entirely -- filed as #480), and the unmeasured latency assertion. Deferred HEAD-instead-of-GET recorded with its reason rather than silently dropped. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 21:42:20 +02:00
timothyandClaude Opus 4.8	90dc864ce5	fix(473): probe media-server remote streams before handing the URL to ffmpeg ... Tuning a channel intermittently hard-failed with ffmpeg exit 8 and `Server returned 404 Not Found` on /media/jellyfin/{itemId}. Root cause: ValidatePlayoutItemPath checked `File.Exists` on the local branch, but the three media-server remote-stream branches returned `http://localhost:{port}/media/{plex,jellyfin,emby}/{id}` unconditionally. When the media was gone from the media server too, validation "succeeded" and ffmpeg was launched against a URL that 404s. That bypassed the good error path the handler already had (PlayoutItemDoesNotExistOnDisk renders an error card sized to run until the NEXT playout item, so the dead item is skipped) and instead landed in HlsSessionWorker's generic ffmpeg-failure path, which sizes its error card to the failed 44s work-ahead chunk and then re-selects the SAME broken item -- a repeating error card for the item's whole slot (~22 min). Restore the method's own invariant: every PlayoutItemWithPath it returns has been checked for existence. A definitive 404 now returns the new PlayoutItemNotAvailableFromMediaServer error, handled in the same switch arm as PlayoutItemDoesNotExistOnDisk. The probe is deliberately fail-open: only a 404 reports the media gone. A timeout, 5xx, auth error or transport failure reports available, so a probe that cannot answer can never break a tune that would have worked. That contract is pinned by tests so a later refactor cannot invert it. Rejected alternatives (see docs/decisions.md): resizing the HlsSessionWorker retry loop (cannot distinguish a dead item from a transient transcoder failure -- prod has live VAAPI hwupload -22 failures that must keep retrying), and writing MediaItemState from the streaming path (breaks scanner ownership, and would not have fixed this: the item is RemoteOnly, which PlayoutBuilder's skip does not exclude). Scanner-side follow-ups filed separately: #476 (FileNotFound does not cascade show -> episodes, the reason dead items keep being scheduled), fixes #473 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 21:41:55 +02:00
timothy	48d7598bae	Merge pull request 'ci(412): sample true peak-anon in the test job, not cache-inflated memory.peak' (#475) from ci/412-peak-anon-sampler into main	2026-07-19 19:09:29 +00:00
timothy	c5369b1d69	ci(412): sample true peak-anon in the test job, not cache-inflated memory.peak ... The test-job memory instrument (#411) reported memory.peak — the high-water mark of memory.current, which charges reclaimable page cache to the cgroup. A build does heavy NuGet/npm/obj/bin/coverage I/O, so cache can dominate the peak, and page cache is reclaimed under a tighter cap rather than OOM-killed. Sizing a per-job cap (server-management#604) off memory.peak therefore inverts the decision. The OOM-forcing quantity is peak anon, which the kernel exposes no counter for and which the end-of-job split misses (a job that peaks mid-dotnet-test then frees reports a low anon). New scripts/ci-peak-anon.sh: a `start` step (before Build/Test/Coverage) launches a detached background sampler tracking the high-water mark of cgroup anon; a `report` step (last) stops it and prints the sampled peak anon as the headline, keeping memory.peak + end-of-job split as a cache-inflated ceiling and reference. Both continue-on-error + fail-open so they never redden a build. Validated on bumblebee: survives step-boundary re-execs, catches a transient 2.5 GiB anon spike the snapshot reports as 0, stops cleanly on kill, degrades gracefully. Compiler-server A/B (swap-off, sampled peak-anon, n=2 interleaved): OFF (CI config) ~5.84 GiB consistent; ON (defaults) 6.3-7.6 GiB, always higher, + a ~3 GiB resident VBCSCompiler. Disabling the servers is worth it, but OFF sits right at 6 GiB for the build phase alone and the test job adds test+coverage, so #406's "budget loosens well under 6 GiB" premise is not supported. Size the cap off the live test-job sampler. Docs: ci-cd.md instrument section rewritten (peak-anon headline + A/B table + premise verdict); decisions.md entry added. No .cs touched. fixes #412	2026-07-19 20:49:08 +02:00
timothy	48d632d50a	Merge pull request 'perf(469): format gate uses dotnet format whitespace --folder (~480s → ~0.5s)' (#471) from ci/469-format-speed into main	2026-07-19 17:59:33 +00:00
timothyandClaude Opus 4.8	33657b4753	docs(469): sweep remaining stale format-job cost/memory claims (review) ... Cold adversarial review (MERGEABLE) flagged two spots still describing the pre-#469 heavy `format` job as current, plus a wording imprecision: - ci-cd.md CI-lane table row: annotate `format` runtime 37s → ~0.5s (#469). - ci-cd.md #406 memory narrative: note the 3.95 GiB Roslyn heap is now moot (folder mode loads no workspace); api-docs remains the lane's real consumer. - Precise the coverage mechanism in ci-cd.md + decisions.md: the naming rule passes the full gate because naming violations have no `dotnet format` batch code-fixer (so `--verify-no-changes` sees no change), not merely a severity floor. Docs-only; no workflow/hook logic change from the reviewed commit. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 19:34:43 +02:00
timothyandClaude Opus 4.8	eafb2e39e2	perf(469): format gate uses dotnet format whitespace --folder (~480s → ~0.5s) ... The blocking `format` CI job and the Husky pre-commit hook verified changed .cs files with `dotnet format ErsatzTV.sln --no-restore --verify-no-changes --include <files>`. `--include` only narrows *which* files are checked, never what gets loaded: the full recipe loaded the ~10-project MSBuild workspace and built a Roslyn compilation per project before checking a single line (~480s locally, whole-solution). Switch both to `dotnet format whitespace . --folder --verify-no-changes --include <files>`, which treats the tree as a plain folder of files, skips MSBuild/Roslyn entirely (~0.5s), and needs no `dotnet restore` (NuGet-cache + Restore steps removed). Coverage is unchanged: folder mode reads .editorconfig and enforces exactly the gate's purpose — whitespace + charset (BOM). Proven non-vacuous (error WHITESPACE on a trailing-space line, error CHARSET on a prepended BOM, exit 0 clean). The full gate never enforced the style/analyzer pass either — a warning-severity naming violation passes the full solution format (exit 0) — and the analyzers that must block (NU1904, S3981) are enforced at compile via WarningsAsErrors, not by this job. Docs: ci-cd.md Formatting section + the obsolete #406 memory note; decisions.md. fixes #469 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 18:33:31 +02:00
timothy	e8d730359a	Merge pull request 'test(444): deterministic functional-E2E for the playout-build lock 409 + isLocked projection' (#470) from feat/444-buildlock-e2e into main	2026-07-19 15:57:41 +00:00
timothyandClaude Opus 4.8	038703fe67	test(444): deterministic functional-E2E for the playout-build lock 409 + isLocked projection ... Adds "Flow C" to scripts/e2e-functional.sh, the last deferred lock-contention flow from #363. A playout build is enqueued onto the single-consumer WorkerService channel and the trigger returns before BuildPlayoutHandler acquires the lock, so an accepted trigger does not prove the lock is held. Flow C makes it deterministic: seed a Classic Flood schedule over a few short ffmpeg episodes, crank PlayoutDaysToBuild=5 (~43k items ~= ~1s build), then POLL GET /playouts/{id} until isLocked:true before firing. Asserts PUT /playouts/{id} -> 409, reset -> 409, and the list-projection isLocked:true while locked; then isLocked:false + PUT -> 200 after the build (proving the 409 is lock-specific). Each racing assertion is guarded so a build that finishes mid-flight degrades to an advisory skip, never a false red; the whole flow self-skips without ffmpeg or if the build is never observed locked. Sized by measurement on a fresh instance -- going wider is counter-productive (a 777k-item build saturates the single worker with post-build gap/overlap jobs). Verified green across 6 fresh-instance runs; cold adversarial review MERGEABLE. Docs: docs/e2e-local.md + docs/ci-cd.md updated to describe Flow C and drop it from the "deferred" lists. fixes #444 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 17:37:50 +02:00
timothy	481a14675f	Merge pull request 'feat(431): TTL-cache health-check results; ?refresh=true forces a fresh run' (#468) from feat/431-health-ttl-cache into main	2026-07-19 13:43:11 +00:00
timothyandClaude Opus 4.8	ca54853b60	style(431): dotnet format the touched troubleshooting handler (#311 fix-as-you-touch) ... The Formatting CI gate flagged legacy stacked-foreach whitespace in GetTroubleshootingInfoHandler.cs (lines ~121-137) — pulled into scope because this PR touches the file (fix-as-you-touch, ersatztv#311). Pure `dotnet format` reindent, zero logic change (git diff -w is empty). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 15:03:48 +02:00
timothyandClaude Opus 4.8	be25df670e	feat(431): TTL-cache health-check results; ?refresh=true forces a fresh run ... GET /api/v1/health re-ran all 14 health checks on every request, 4 of which shell out to ffmpeg/ffprobe via CliWrap — so each poll spawned ~4 subprocesses. The existing HealthCheckSummary cache was write-only. Cache the full result list for 30s inside HealthCheckService keyed on a new "healthcheck.results" entry; a non-forced call returns it on a hit, skipping the checks and the (subscriber-less) summary publish. Add a `bool forceRefresh` first parameter to IHealthCheckService.PerformHealthChecks: the API poll path reads the cache, while startup (RunHealthChecksService) and the troubleshooting support bundle force a fresh run. Refresh surface: GET /api/v1/health gains an optional `[FromQuery] bool refresh` (additive, follows the ?deep= exemplar); the SPA "Refresh health" button calls /api/v1/health?refresh=true, the initial/poll load does not. Tests: HealthCheckService cache-hit vs force-bypass (mutually opposing, non-vacuous), handler+controller refresh-flag threading, SPA refresh URL. Docs: decisions.md 2026-07-19 (#431), api-conventions §2; regenerated v1.json. fixes #431 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 14:41:12 +02:00
timothy	67dc9ca4c0	Merge pull request 'fix(464): render real channel logos in guide grid + channels list' (#467) from fix/464-guide-logos into main	2026-07-19 12:10:28 +00:00
timothyandClaude Opus 4.8	1aa1f0cf5b	fix(464): render real channel logos in guide grid + channels list ... The guide/EPG grid (/app/guide) and the channels list (/app/channels) always drew the generated initials "bug" because the browse DTOs never carried a logo URL — GuideScreen/ChannelsScreen rendered <ChannelLogo> with no src. The logo data existed (it round-trips through the channel editor) but never reached these views. Add a rooted, directly-usable Logo URL to ChannelGuideChannelResponseModel and ChannelResponseModel, populated by a single Channels.Mapper.GetLogoUrl helper (#181 artwork convention): /iptv/logos/{file} for an uploaded logo, the absolute URL passed through for an external one, null when unset so the SPA keeps its generated-initials fallback. The guide query now includes Channel.Artwork. Regenerated OpenAPI + v1.d.ts; updated api-conventions.md + domain-model.md. fixes #464 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 13:28:00 +02:00
timothy	a6c300730b	Merge pull request 'docs(404): mirror the weight UI into the MultiCollections design prototype' (#466) from docs/404-designsync-mirror into main	2026-07-19 11:25:26 +00:00
timothyandClaude Opus 4.8	586b075cc1	docs(404): mirror the weight UI into the MultiCollections design prototype ... Design-sync back-mirror of the #404 weight UI (PR #462) into the Claude Design prototype so repo + Claude Design stay byte-identical (docs/design-sync.md step 7). Pushed to the ChicoryTV Design System project via DesignSync in the same session. The prototype's EditItemRow now shows a per-source Weight input (1..1000) + computed % share, and the editor gains a "Reset to fair share" footer — a faithful mockup of the shipped screen. Prototype-only (design-system/), no shipped code. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 13:05:07 +02:00
timothy	cc2968de15	Merge pull request 'fix(463): bound the schedules "Active schedule" selector so it stops overlapping the header' (#465) from fix/463-schedule-select-width into main	2026-07-19 10:21:00 +00:00
timothy	86cbf79b48	Merge pull request 'feat(404): weighted-distribution SPA — per-source weight inputs + WeightedShuffle order' (#462) from feat/404-weight-ui into main	2026-07-19 10:01:41 +00:00
timothyandClaude Opus 4.8	df617a64c7	fix(463): bound the schedules "Active schedule" selector so it stops overlapping the header ... The header selector rendered at the Select default `fullWidth=true`, which applies `.ctv-field-full { width: 100% }`. In the flex `.ctv-schedule-header` that made it demand the whole row, overlapping/distorting the title block and Add/Edit/Delete buttons. Pass `fullWidth={false}` (sizes to content) + bound it to 150–260px so a long schedule name can't re-widen it; the native select's value truncates within the frame (`.ctv-select { min-width: 0 }`). Pure-SPA/CSS, no API/DB change. Regression test asserts the selector wrapper is not `.ctv-field-full`. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 11:58:22 +02:00
timothyandClaude Opus 4.8	d2d678aae8	test/docs(404): add unrelated-edit round-trip test; correct MultiCollection-only rationale ... Review + live-E2E follow-ups (no behavior change): - Add a test proving the canonical silent-reset trap directly: a rename-only save round-trips both weights untouched (the prior test only edited the weight it asserted). Cold review nit. - Correct the rationale in itemRules.ts + decisions.md: WeightedShuffle is MultiCollection-only in the SPA for *meaningfulness* (per-source weights need 2+ sources), NOT because the classic write path rejects it — live-E2E confirmed the classic engine ACCEPTS it on a plain Collection (200) and degrades to fair-share. The rejection is on the separate playlist/block write paths, whose editors keep their own order lists and already omit it. Live-E2E (real API): weighted multi-collection create + read round-trips weights; rename-only PUT preserves them (no silent reset); WeightedShuffle persists on a classic MultiCollection schedule item. Ratio itself is pinned by the existing PlayoutBuildGoldenTests.Classic_weighted (3:1), untouched by this SPA change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 11:39:29 +02:00
timothyandClaude Opus 4.8	d639946b5c	feat(404): weighted-distribution SPA — per-source weight inputs + WeightedShuffle order ... The UI half of #70 (backend + API shipped in PR #402). Pure SPA + docs — no new endpoint/DTO (`weight` was already on MultiCollectionItemRequest/Response, and `WeightedShuffle` already in the PlaybackOrder enum). - Multi-collection editor (`/app/multi-collections`): per-source weight input (1..1000, mirroring the API validator), a computed % share (3:1 shows 75/25), and a "Reset to fair share" action (fair-share = all weights 1, decisions.md 2026-07-17 — a reset, not a separate mode). Weight round-trips through the draft (read in itemsFromMultiCollection, written in toItemRequest) so the replace-all PUT never silently resets it. - Classic schedule editor: `WeightedShuffle` offered as a Playback Order ONLY for MultiCollection sources (itemRules `MULTI_COLLECTION_ORDERS`) — it needs per-source weights and the write path rejects it elsewhere. Excluded from fillWithGroup like ShuffleInOrder (PlayoutBuilder schedules fill-groups per-group, incompatible with whole-collection weighted share). - `Input` gained min/max/inputMode/onBlur passthroughs for bounded numeric fields (reusable by #425's weight UI); weight held as a string for smooth editing, clamped on blur and at save so an out-of-range value never 400s. - Docs: domain-model + spa-conventions (replace-all round-trip trap, bounded numeric input pattern) + decisions.md entry. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 11:28:12 +02:00
timothy	996c545161	Merge pull request 'feat(queue): deterministic select-queue.sh — stop re-deriving the selector by hand' (#461) from feat/select-queue-script into main	2026-07-19 08:46:18 +00:00
timothyandClaude Opus 4.8	708e602197	feat(queue): deterministic scripts/select-queue.sh — stop re-deriving the selector by hand ... The kickoff dispatches a cheap model to rank the backlog, and the lore then made the orchestrator re-derive its mechanical claims (deps, milestone tiering, priority order, in-progress state) because a small model kept getting them wrong. This pays that tax down: the mechanical checks are now CODE — GET /dependencies exclusion, LOCAL .milestone.state/review/priority tiering (never the no-op ?milestones= filter), (tier,priority,issue#) ordering, in-progress/parked/PR exclusion — leaving only two JUDGMENT flags (CLAIM?, UMBRELLA?) for a human/model to resolve. - scripts/select-queue.sh: fail-open on no-creds/unreachable; ~1.3s; shellcheck clean; UMBRELLA? computed in the jq pass (no per-candidate body fetch). - handoff kickoff: run the script FIRST; trust its deps/tiering/ordering, recheck only flags. - handoff lore: the three 'cheap selector unreliable → re-derive by hand' bullets kept as the EVIDENCE for why the script exists; the prescription is redirected to 'run the script'. Operator-requested this session: 'rather than have the lore make us redo the selector's work, improve the selector.' Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 01:09:57 +02:00
timothyandtimothy	df8c5202d6	fix(409): report never-scanned LastScan as null for API/MCP parity (migration + read coercion) (#459) ... Co-authored-by: Timothy <timothy.look@gmail.com> Co-committed-by: Timothy <timothy.look@gmail.com> v26.10.0	2026-07-18 19:39:25 +00:00
timothyandClaude Opus 4.8	2fff5fc05d	Merge pull request 'feat(420): skip re-validating an already-green identical merge tree' (#455) from feat/398-420-ci-build-once into main ... feat(420): skip re-validating an already-green identical merge tree (#455) Standalone cross-run tree-identity skip. Build-once (#398) was measured and rejected. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 19:14:27 +00:00
timothyandClaude Opus 4.8	dd55f00ed4	docs(420): sharpen the skip's honest hit-rate (rebase-before-merge) + cite live combined-status check ... Review nits from the scoped #420 review. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 20:53:23 +02:00
timothy	922b1ef53c	docs(398,420): document the #420 skip + record build-once measured-and-rejected	2026-07-18 20:53:23 +02:00
timothy	eb12176fe1	ci(420): skip re-validating an already-green identical tree on merge-to-main	2026-07-18 20:52:44 +02:00
timothy	8152afead1	Merge pull request 'feat(403): make unsupported PlaybackOrder loud at build time + tripwire' (#457) from feat/403-loud-playbackorder into main	2026-07-18 17:10:35 +00: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