819 Commits

Include renames

Author	SHA1	Message	Date
timothyandtimothy	ba6a4b08aa	feat(732): On Now / Next gets a background box, and is on by default (#843) ... Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-26 19:28:25 +00:00
timothyandtimothy	08cd3a002d	fix(690,758): count the same query a paged handler pages (#833) ... Co-authored-by: Timothy <timothy@noreply.gitea.tblindustries.be>	2026-08-26 07:39:23 +00:00
timothyandClaude Opus 5	b5dee26202	fix(701): guard SongMetadata's nullable primitive collections at the read site ... Both search indexers opened UpdateSong with metadata.AlbumArtists ??= []; metadata.Artists ??= []; Artists/AlbumArtists hold the whole list in ONE COLUMN rather than being navigations. So unlike the same `??= []` idiom on Genres/Tags/Artwork all around them, the property IS the column value: assigning it on a TRACKED entity flips the entry to Modified and the next SaveChanges writes [] over a NULL column. This is the mechanism an adversarial review demonstrated in #691, which is why that issue's entity-level guard was reverted in favour of guarding at the read site. Measured rather than reasoned about, per the issue's first done-when box. Restoring ONLY the `??= []` clause (the real predecessor lines, not a hand-written mutant) reddens the new fixture on `metadata.Artists should be null but was []`; a probe variant with the first two assertions replaced by prints reports STATE=Modified and the raw column moving from NULL to "[]". Today's two feeds are both AsNoTracking (SearchRepository.GetItemToIndex and GetAllSongs), so no shipped caller loses data -- but that is a property of two callers, not of the indexer, and #691 already recorded it as a loaded gun. The fixture pins the indexer's own contract instead. Removing the assignment is not sufficient alone: it was load-bearing for the four reads below it, and deleting it by itself converts a silent write into a live throw on every untagged song. Measured by deleting only those two lines from the real predecessor file: NullReferenceException, thrown at the foreach (cited by symbol: a line number in a mutant that exists in no committed tree is unreproducible by construction). The exception type follows the read FORM, not the field -- foreach yields NRE, string.Join/ToList yield ArgumentNullException -- and this PR contains two of each, which is why no single exception-name grep characterises the class. So each site moves together with its reads: - LuceneSearchIndex.UpdateSong / ElasticSearchIndex.UpdateSong: hoist Optional(...).Flatten().ToList() locals and read those. - RefreshChannelDataHandler: the Scriban context took the raw nullable lists (the issue's second item). The shipped _song.sbntxt only does array.join, but a custom template is free to do anything. The population was derived from the MODEL rather than from the issue's file list, and the obvious derivation is wrong: "the IList<string> properties under ErsatzTV.Core/Domain" returns two of eight. It misses the six value-converted collections (ProgramScheduleAlternate and PlayoutTemplate each carrying DaysOfMonth, MonthsOfYear, DaysOfWeek), declared as plain ICollection<T> and made single columns only in Data/Configurations -- and their storage differs (comma-separated text for the int converter, JSON for the enum one), so the shared property is "one scalar column", not the serialization. No site applies `??=` to any of the six, so this defect has no instance there; whether a null can REACH one at runtime is unverified and is filed as #823 rather than asserted either way. Only the SongMetadata pair is left NULL in practice, by FallbackMetadataProvider. Every site touching either field was then swept; the remaining readers were already guarded by #691. The fixture carries two anti-vacuity guards, both witnessed: - A POSITIVE CONTROL (`writer.NumDocs.ShouldBe(1)`). Every other assertion says something did NOT happen, so all of them hold vacuously if UpdateSong never runs -- and it silently stops running if a future refactor gates UpdateItems on `_initialized`, which this fixture bypasses by injecting the writer. Verified BOTH directions: with that gate added the control fails `NumDocs should be 1 but was 0`, and with the control removed the whole test PASSES while the code under test is unreachable. - A capturing logger, because UpdateSong wraps its body in a catch that assigns metadata.Song = null -- severing a required relationship and cascading the metadata to Deleted. Without it the probe silently measures the error path; on the first run it did exactly that (a bare ILanguageCodeService substitute NPEs inside AddLanguages). The raw column helper also fails loudly on a missing row, since ExecuteScalar returns CLR null for both "NULL column" and "no such row". ElasticSearchIndex has no equivalent fixture -- it needs a stubbed transport -- so its change is by inspection against the Lucene one, and the gap is filed as #824 rather than covered by a source-text guard. The whitespace-only churn in ElasticSearchIndex.cs is the #311 fix-as-you-touch format gate: it scopes to whole changed FILES. `git diff -w` over that file shows only the two hunks above. Local gate: ErsatzTV.Tests 2006 passed / 4 pre-existing skips, Core.Tests 685/1 skip, Infrastructure.Tests 114, Architecture.Tests 7, Scanner.Tests 1504 -- 0 failures in each. scripts/tests 874 passed / 2 skipped. dotnet format whitespace --verify-no-changes clean on the four touched files, no BOM on any. decisions_validate OK. Fixes #701 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-23 00:49:57 +02:00
timothyandClaude Opus 5	dd7b58232c	fix(691): revert entity-level null guard, guard read sites instead ... The prior commit (a4700185b) made SongMetadata.Artists/AlbumArtists coalesce null to [] via backing-field getters, reasoning that EF Core's PreferField access mode never observes the getter. Adversarial review disproved this on real TvContext/SQLite: a single read of .Artists on a TRACKED entity mutates the backing field through the getter, flips the entity to Modified, and the next SaveChanges writes [] over what was a NULL column -- silent data loss waiting on the first tracked reader (today all readers happen to be AsNoTracking). This also reversed docs/decisions/records/api/selection-projection-include-chain.md (#671) without the doc update CLAUDE.md requires; #691 is that record's own "sweep by FIELD" follow-up, so it should follow the record, not contradict it. Revert SongMetadata.cs to plain auto-properties (byte-identical to origin/main, BOM still stripped per the #311 gate). Guard the read sites instead, per the #671 convention (Optional(...).Flatten(), matching Playouts/Mapper.cs and MediaItems/Mapper.cs): - SongVideoGenerator.cs: hoist `artists`/`albumArtists` locals once near the top of the metadata loop instead of repeating the guard at each of the six former call sites. - MediaCollectionRepository.cs (GroupIntoFakeCollections): guard the two AlbumArtists reads at lines ~1147/~1160 that #691 never named -- dropping the entity-level fix without these would trade one bug for two. Verified RED per guard by removing only the Optional(...).Flatten() clause (not the whole file): the artists local throws ArgumentNullException at SongVideoGenerator.cs:88, the albumArtists local at :89 (List.ToList() on a null IList<string> source -- same loaded-gun shape the review demonstrated, precise exception type is ArgumentNullException rather than NullReferenceException since the throw site is Enumerable.ToList's null-source check). Restored both; existing SongVideoGeneratorTests still pass. Full ErsatzTV.Core.Tests: 685 passed (1 pre-existing skip), ErsatzTV.Tests: 1996 passed (4 pre-existing skips), 0 failures in each. No EF model drift (`dotnet ef migrations has-pending-model-changes` reports none). `dotnet format --verify-no-changes` on the three touched files exits 0. Refs #691 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 22:39:52 +02:00
timothy	05542946ad	fix(668): reach accented facet values via a registered Unicode fold on SQLite ... SQLite's LOWER() folds ASCII only -- lower('Édith') is 'Édith' unchanged -- so the EF-sourced facet fields UNDER-matched any stored value whose prefix carries an uppercase non-ASCII character. An under-match is unrecoverable: no later stage can reintroduce a row SQL never returned. Adds a SECOND, ADDITIVE query taken only when the provider is SQLite and q contains a non-ASCII character: raw Dapper SQL folding through etv_upper(), a SqliteConnection.CreateFunction scalar implementing ToUpperInvariant. Every other case -- all-ASCII q, and MySQL for all q -- runs the existing EF query byte-identically. MySQL needed no change and gets none: verified on MySQL 8.4 that its LOWER() is Unicode-aware and its ci collation makes the predicate OVER-match, which the existing ordinal filter already discards. The fold is ToUpperInvariant because OrdinalIgnoreCase equality is a strict SUBSET of invariant-uppercase equality, so the SQL stage yields a superset of the final filter's matches and can never under-match. Note OrdinalIgnoreCase is NOT "invariant-upper then ordinal": ToUpperInvariant('ſ') is 'S', yet "ſweet".StartsWith("S", OrdinalIgnoreCase) is false. Tests pin that. No migration, no model change; both provider snapshots are untouched. Refs #668 Decisions-Edit: yes	2026-07-27 20:36:28 +02:00
timothy	83cd36e0de	test(491): run the dedupe fixture against MySql in CI; correct the collation claim ... The dedupe DML had zero automated coverage on MySql: the migrations job only applies migrations to a fresh EMPTY database, so no dedupe row ever executed there. Two MySql-only collation defects escaped that gate in this session and were caught only by hand-run containers. Parameterize LibraryFolderDedupeMigrationTests over both providers from ONE fixture body - same seeded rows, same expected survivors - rather than adding a MySql-only copy that would drift and recreate the gap. Assertions no longer use WHERE Path = '...', which is itself collation-dependent and would quietly mean something different per provider; rows are read once and compared ordinally in memory. A new step in the existing migrations job runs it against that job's mysql:8.4 service, on a per-test database of its own. Proven red when the collation is wrong: restoring COLLATE utf8mb4_bin fails the MySql half with survivors [1,4,5,6,7,9] - the trailing-space sibling deleted - while SQLite stays green. Proven non-skippable: without ETV_TEST_MYSQL_CONNECTION the fixture ignores visibly, and with ETV_REQUIRE_MYSQL_TESTS=1 (which CI sets) that skip becomes a hard failure, so it cannot pass having connected to nothing. Local runs need no MySql. Also correct an overstated comment. The schema pins only the utf8mb4 charset, never a collation, so the effective comparison is the server default: always case-insensitive, but PAD SPACE only on utf8mb4_general_ci - 8.4's default utf8mb4_0900_ai_ci is NO PAD, verified on the real column. The migration bug was independent of that because the old code applied an EXPLICIT utf8mb4_bin, which is PAD SPACE everywhere; the runtime simply tolerates both. Refs #488 #308 fix #491	2026-07-25 21:13:31 +02:00
timothy	48d41b9235	fix(491): make the MySql dedupe byte-exact, not just case-exact (PAD SPACE) ... Cross-family review of 1b4dd6d6 found that utf8mb4_bin - chosen to keep the dedupe case-exact - is a PAD SPACE collation, so trailing spaces are insignificant under it. Verified on MySQL 8.4: '/media/Foo' = '/media/Foo ' is TRUE, while case correctly compares unequal. Two distinct legal directories therefore grouped together and the second was DELETED irreversibly, even though PathUtils.GetPathHash hashes them differently and the unique index about to be created would have accepted both. The dedupe destroyed data the constraint never required it to destroy. Group and join on CONVERT(Path USING binary) instead - NO PAD and byte-exact, matching the hash. utf8mb4_0900_bin is also NO PAD but carries a server-version floor. This is the only path comparison in either migration (every other predicate keys off an integer id), so there is no mix of padded and unpadded comparisons across the keeper-selection, repoint and delete steps. SQLite's = on TEXT is byte-exact with no padding, so that migration was already correct - which is exactly why a SQLite-only test could not see the divergence. The two providers are now semantically equivalent, and the dedupe fixture is shared: same rows, same expected survivors (1,4,5,6,7,9,10), asserted by the SQLite test and reproduced by hand on MySQL 8.4. Runtime was never affected, and this is now stated and tested rather than assumed: GetFolder's SQL equality is a superset narrowing (both collation quirks make it more permissive, never less, so it cannot miss a byte-exact match) and ResolveExact settles identity with StringComparison.Ordinal, which compares length first. Added ResolveExact coverage for the trailing-space axis. Refs #488 #308 fix #491	2026-07-25 21:13:31 +02:00
timothy	50eff83628	docs(491): reattach the case-exact lookup rationale to GetFolder ... Review follow-up. ResolveExact was inserted between GetFolder's summary and GetFolder itself, leaving ResolveExact with two summaries and GetFolder with none -- so the H1 rationale (SQL equality is only a narrowing filter; OrderBy(Id) for determinism) described neither of the things ResolveExact does. On a fix that turns on exactly that reasoning, a misattached explanation is what misleads the next reader.	2026-07-25 21:13:31 +02:00
timothy	ecb763ea58	fix(491): review polish — heal cannot abort a scan, ordinal settle unit-tested ... Final low-severity items from the re-review of ee10f932. L2: DbUpdateConcurrencyException derives from DbUpdateException but carries no provider exception, so IsUniqueConstraintViolation does not classify it. A row deleted by a concurrent library edit between the heal's read and its save would propagate and fail the scan, contradicting the invariant stated directly above it. Admit it in the filter. L1: lift the in-memory ordinal settle into LibraryRepository.ResolveExact and unit-test it with both spellings in the candidate list. No SQLite-backed test can exercise it (SQLite's = on TEXT is already binary), so this converts the half that rested on hand-run MySQL evidence into automated coverage. The end-to-end companion test's comment no longer claims to be provider-independent. L4: assert PRAGMA foreign_keys is 1 before migrating, so the enforcement guard cannot silently degrade into the weak pre-fix form it was added to replace. L3: detach the failed heal, matching the insert path. N3: the heal's inner predicate now matches its IsNullOrEmpty outer guard, so a PathHash = '' row cannot enter the branch and silently never heal. N4: record that GetFolder returning null for a case-differing spelling makes MySQL insert a second row where it used to reuse one — correct, and now matching SQLite, but a real behaviour change on a case-insensitive filesystem. Refs #488 #308 fix #491	2026-07-25 21:13:30 +02:00
timothy	14e9b03433	fix(491): wire the unique-violation classifier in the scanner; make folder lookup case-exact ... Review of 491f5099 found the fix inert in the only process that runs it, plus a MySQL collation defect in the lookup. B1 — TvContext.IsUniqueConstraintViolation was assigned only in ErsatzTV/ Startup.cs, but ErsatzTV.Scanner is a separate executable and every production caller of GetOrAddFolder/SetEtag lives there. The classifier kept its '_ => false' default, so the catch never ran and the DbUpdateException failed the whole scan - worse than the duplicate row it replaced. Wire both provider branches in ErsatzTV.Scanner/Program.cs, and add ProviderStaticsWiringTests (architecture) asserting the scanner assigns every TvContext static the host assigns, with IsSqlite documented as the one exemption. H1 — GetFolder's 'Path == folder' is case-insensitive on MySQL while PathHash is case-sensitive, and FirstOrDefault was unordered: a scan of '/x/foo' could resolve the '/x/Foo' row and stamp the wrong hash onto it (verified on MySQL 8.4: the WHERE matches both, LIMIT 1 returns the wrong one). Treat the SQL equality as a narrowing filter, order by Id, and settle identity ordinally. Route the heal through EF and drop a classified violation, so an opportunistic maintenance write can never abort a scan. Also: run the dedupe migration test with foreign keys ON (matching prod), clear the keeper's etag, null out a self-parent, and document the cleanup's limits (NULL paths excluded, Down does not restore deleted rows, CI's fresh-DB apply covers none of the data mutation). Refs #488 #308 fix #491	2026-07-25 21:13:30 +02:00
timothy	9a4f3e832d	fix(491): unique index on LibraryFolder(LibraryPathId, PathHash) + tolerate concurrent insert ... GetOrAddFolder was a check-then-insert with no unique constraint behind it, so two callers racing the same folder could both miss the lookup and both insert. Enforce identity in the schema and make the loser adopt the winner. - LibraryFolder gains a SHA-256 PathHash (the MediaFile.Path/PathHash precedent): Path is MySQL longtext, which cannot be indexed without a prefix length and collates case-insensitively, so the unique index is on (LibraryPathId, PathHash) instead. - GetOrAddFolder and SetEtag catch a classified unique violation via the existing TvContext.IsUniqueConstraintViolation seam (#308) and re-read. - Dual-provider migration audits and collapses pre-existing duplicates (repointing MediaFile, ParentId and ImageFolderDuration) before creating the index; legacy rows keep a null hash and heal on the next scan. - Tests: deterministic cross-connection race, 8x10 barrier stress with an insert-attempt vacuity guard, classifier-inversion negative control, and a real-migration dedupe test. Refs #488 #308 fix #491	2026-07-25 21:13:22 +02:00
timothy	147166b053	fix(496): harden the legacy path sweep against MySQL collation (re-review Low) ... Re-review returned MERGEABLE with one Low, MySQL-collation-dependent edge in FlagFileNotFoundByPaths: the C#-side Except diff is ordinal, but `MF.Path IN @LocalPaths` runs under MySQL's case-insensitive default collation, so a still-reported identified row differing only in case from an absent legacy row could be matched and flagged missing. Match on the indexed PathHash instead of collated Path text, and re-state the NOT EXISTS (JellyfinMusicVideo) guard so the identity pass and the legacy pass are disjoint by construction rather than by the caller's diff being correct. SQLite was unaffected.	2026-07-25 17:20:53 +02:00
timothy	6bd1d954bd	fix(496): review fixes — thread the replaced local path, scope identity per library, sweep legacy rows [decisions-edit] ... Independent cold review (Codex) returned BLOCKED. Findings 1, 3 and 4 are fixed here; each has a regression test proven non-vacuous by a negative control. 1. Blocker — the replaced local path was discarded. The scanner computed localPath but GetOrAdd only received `incoming`, so the repository re-derived the path from the UNREPLACED projection. On any install with path replacements, adoption hashed the server-side path, missed the existing row, ALSO slipped past MediaFileAlreadyExists (which hashes that same wrong string) and inserted a duplicate row under a server path, leaving the original collection-linked row identity-less forever. The test harness hid this because its path-replacement stub was an identity function. → GetOrAdd now takes localPath explicitly and never reads the projection's path; BuildPathReplacement takes a real mapping and the new test genuinely replaces. 3. Medium — GetByItemId matched on ItemId alone, so two media sources presenting the same item id (cloned Jellyfin DB) resolved to each other's row, letting one library repoint another's. → filtered by LibraryPath.LibraryId. 4. Medium — a row predating the identity that the server had ALREADY stopped reporting was never adopted (adoption only runs for an incoming item) and carried no identity, so the itemId diff could not see it either: it sat Normal and schedulable forever, strictly worse than the hard delete it replaced. → GetExistingLegacyMusicVideoPaths + FlagFileNotFoundByPaths reconcile legacy rows by local path, and they are counted into the #477 empty-fetch guard (on the first scan after this ships they ARE the whole library, so a guard counting only identity rows would sweep all of them on a transient empty fetch). Finding 2 (the issue's Done-when #2) is a scope question, not a defect, and is unchanged: one file path is still one MediaItem row globally, so this lands music videos at parity with movies rather than eliminating shared-row trashing. Recorded honestly in the decision record; raised for an explicit call before the issue is closed. fixes #496	2026-07-25 17:20:53 +02:00
timothy	64decd492e	fix(496): give music videos a per-library server identity; itemId diff + soft trash ... Music videos carried no server identity, so JellyfinMusicVideoLibraryScanner had to reconcile by a (LibraryPathId, path) diff and HARD-delete the remainder. A file served by two libraries with overlapping local paths is a single row owned by whichever library scanned it first, so that owner's sweep destroyed a row another library still served — taking collection membership and playout references with it, irreversibly. This is #494's deferred "option 2": - New JellyfinMusicVideo : MusicVideo (ItemId/Etag), mirroring JellyfinMovie — TPT table, varchar(36), ItemId index. Dual-provider migration Add_JellyfinMusicVideo. - New IMediaServerMusicVideoRepository + JellyfinMusicVideoRepository: itemId-keyed existing-set/lookup and Flag{Normal,Unavailable,FileNotFound} seams, all scoped per library via LibraryPath.LibraryId. - New MediaServerMusicVideoLibraryScanner base; JellyfinMusicVideoLibraryScanner folds onto it and keeps the #177/#488/#497/#500 metadata-reconcile logic verbatim. - The sweep now soft-trashes (FileNotFound) instead of deleting, so removal is reversible and EmptyTrash-governed. DeleteEmptyArtists consequently no longer fires from a sweep. - Pre-identity rows are ADOPTED in place: the identity row is inserted against the same MediaItem id, scoped to the scanned library's own LibraryPath, so collection membership survives and a local/second-library row is never hijacked. - AddMusicVideo normalizes Path/PathHash to the path-REPLACED local path; the projection fills them from the server-reported path, which would break every later PathHash lookup. Docs: scan.musicvideo-reconciliation relocated to docs/decisions/archive/scan.md as superseded; new active record scan.musicvideo-server-identity. fixes #496	2026-07-25 17:20:53 +02:00
timothy	6f4497e1ce	fix(484): guard the nested TV season and episode sweeps against projection failures ... Review finding 1 (blocking). ScanSeasons' FlagFileNotFoundSeasons and ScanEpisodes' FlagFileNotFoundEpisodes had no guard at all — neither #477's nor #484's — so ProjectToSeason / ProjectToEpisode returning Failed() was computed and discarded. #477 scoped those out because "the blast radius is one show's seasons / one season's episodes", which holds for a per-parent EMPTY fetch but not for a projection failure: that is systematic by construction. One bad code path fires on every parent, so every season enumerates zero episodes, existing.Except([]) is the whole episode library, and EmptyTrashHandler deletes it permanently. Threads the counter into GetSeasonLibraryItems / GetEpisodeLibraryItems(WithoutPeople) for Jellyfin and Emby using the same optional-trailing-param shape, and guards both sweeps with MediaServerReconciliationGuard.ShouldFlagMissingDescendants — the same class and the same private failure predicate as ShouldFlagMissing, deliberately WITHOUT #477's empty-fetch branch so per-parent empty behaviour (and #476's cascade, which depends on it) is unchanged. Also from the review: - finding 3: tests now pin the same-instance JOIN at every level (movie, show, season, episode, music video) by driving the real ScanLibrary entry point and recording the failure from inside the enumeration, so a refactor handing the api client a fresh counter goes red. - finding 4: the missing-library Failed() branch is documented as defensive and unreachable. - finding 2: the mass-Skip residual (Emby's response-shape-dependent MediaSources guard, Plex's pre-projection filter) is stated as a known limitation in the decision record. - finding 5: the log-contract change (only the #484 message when both refusals apply) is noted. fixes #484	2026-07-25 16:36:35 +02:00
timothy	e3645a2840	feat(484): suppress the media-server sweep on projection failures; reject the ratio threshold ... Extends MediaServerReconciliationGuard (#477) with a second deterministic refusal: when the enumeration that produced the incoming set silently dropped items whose projection THREW, the file-not-found sweep is refused. A dropped item the server did return is indistinguishable from a deletion at the reconcile step, so a projection regression could otherwise mass-flag a healthy library FileNotFound (which EmptyTrash then deletes permanently). Deliberate guard-clause skips (STRM files, virtual items, unsupported types) are explicitly NOT failures and never suppress a sweep — counting them would permanently disable reconciliation for any library holding a single STRM file. The ratio / missing-fraction threshold is REJECTED, not deferred: it is a two-sided heuristic with no tunable default and no telemetry, and the failure it approximates is exactly observable via the projection-failure count (a genuine bulk deletion produces zero failures). Seam is deliberately narrow — the private ProjectTo* contract inside each api client changed from Option<T> to MediaServerProjectionResult<T> (projected/skipped/failed), the paged helper counts IsFailure in one place, and the scanner reads it through an optional trailing MediaServerProjectionFailureCounter on only the five library-level methods that feed a sweep. The counter is per-enumeration state created by the scanner, never a field on an api client. fixes #484	2026-07-25 16:36:35 +02:00
timothy	890745d1d4	fix(460): write null LastScan on disable-sync instead of the MinValue sentinel [decisions-edit] ... MediaSourceRepository's Plex/Jellyfin/Emby remove-and-recreate (disable-sync) flows stamped SystemTime.MinValueUtc into library.LastScan, so normal use kept minting 0001-01-01 sentinel rows. #409 fixed the READ side (the API coerces the sentinel to null and a migration cleaned the historical residue), so the wire contract was already correct — this stops new sentinel rows being written. Safe because every remaining LastScan reader either coalesces (LastScan ?? SystemTime.MinValueUtc) for its own non-nullable scan-comparison needs, or is the API read-boundary coercion itself — audited every reference under ErsatzTV{,.Application,.Core,.Infrastructure,.Scanner,.Mcp} plus web/. There is no Where/OrderBy/GroupBy on LastScan anywhere, so the SQL null-ordering divergence between SQLite and MySQL has no surface here. Scan-comparison behavior is unchanged. Deliberately ships NO second cleanup migration: rows written between #409's NullOutNeverScannedLastScan and this change keep the sentinel at rest, and the permanent read coercion — not a migration — is what keeps the contract honest for them (as it must be anyway for a restored or hand-edited DB). LibraryPath.LastScan is likewise left untouched: the flows re-add Paths with their original values, and its only readers are the local-library scan handlers, so it has no API surface and no remote-scan effect. Regression test per provider (MediaSourceRepositoryDisableSyncTests), proven non-vacuous: restoring the MinValue writes fails all three. [decisions-edit] — the media.lastscan-null-boundary record documented this write as an ONGOING sentinel source and rested its "the coercion is permanent" argument on it, so the rationale prose is corrected in the same PR per docs.decision-lifecycle. The Rule line is unchanged, so the generated decisions/README.md catalog is byte-identical. MediaSourceRepository.cs also loses its UTF-8 BOM (fix-as-you-touch, #311). fixes #460	2026-07-25 13:46:09 +02:00
timothyandtimothy	65c0e09179	feat(415): per-channel fault detection — server-derived health object + Problems filter (#581) ... Closes #415. Server-derived health object on the channel list + detail DTOs (built-timeline detection, kind-agnostic across all 5 PlayoutScheduleKind; assessable gate keyed to the owning channel's mode), single "Problems" SPA filter with per-fault badges. Supersedes #72's api.channel-health-signal decision. Co-authored-by: Timothy <timothy.look@gmail.com> Co-committed-by: Timothy <timothy.look@gmail.com>	2026-07-23 20:45:19 +00:00
timothyandClaude Opus 4.8	892f4e354b	fix(570): On Now/Next overlay YAML renders — font_family + format_datetime ... The #74 seeded on-now-next.yml never rendered at transcode time: - format_datetime was called with 2 args; it needs 3 (DateTimeOffset, timeZoneId, format) and does the tz conversion itself, so the Scriban render threw. Drop the NEXT start-time (avoids hardcoding a timezone in a shipped default). - styles had no font_family; CustomFontMapper.TypefaceFromStyle crashes on a null family before its default-font fallback. Add font_family: Noto Sans. Verified live on ersatztv-test via frame capture. Adds a seeder test that deserializes the YAML and asserts base_style resolves + every style sets a font. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:10:35 +02:00
timothy	7757814766	feat(74): channel graphicsElementIds + graphics builtIn; regen OpenAPI	2026-07-22 22:11:46 +02:00
timothyandClaude Opus 4.8	fe0a273aad	feat(74): add ChannelGraphicsElement join + dual-provider migration ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 22:11:45 +02:00
timothy	9c6b524aed	feat(74): seed built-in on-now-next.yml text element (file + marker)	2026-07-22 22:11:45 +02:00
timothy	b45dcc7190	fix(177): map Album/Track in the Jellyfin music video projection ... Jellyfin-sourced music videos rendered weaker MTV-style credits than local NFO libraries: the Scriban credits templates expose Album/Track, and MusicVideoNfoReader has always mapped both, but the Jellyfin projection never did. ChronologicalMediaComparer orders music videos by the same two fields, so they were also ordering worse. Verified against the live server (1437 MusicVideo items): Album comes back on 111 and IndexNumber on 4, both WITHOUT being named in the `fields` query param -- Album is a plain BaseItemDto property, not an ItemFields value, so no Refit `fields` change is needed (and adding one would be wrong). ParentIndexNumber is deliberately NOT used for Track: on live data, where both are present ParentIndexNumber is 1 while IndexNumber carries the real ordinal, and where only ParentIndexNumber is present it is a collection/disc grouping that tracks the Album ("Glastonbury: 2022" -> 230). The fix is two layers, not one. The projection alone would only ever reach music videos ADDED after it -- UpdateMetadata copies scalars field by field, so an existing item whose album/track is set or corrected in Jellyfin would keep a stale value forever. That is the same class of bug #497 fixed for child collections, one layer up. Also strips a pre-existing UTF-8 BOM from JellyfinLibraryItemResponse.cs, which the format gate flags once the file is touched (format-as-you-touch). fixes #177	2026-07-21 23:21:10 +02:00
timothyandClaude Opus 4.8	dfed9a393b	fix(68): rebuild on-demand channel guide (and mirrors) on thaw ... An on-demand channel (`PlayoutMode.OnDemand`) already is the "resume where I left off" feature: `Playout.OnDemandCheckpoint` persists the viewer's position and `PlayoutTimeShifter.TimeShift` slides the materialized timeline forward on tune-in so the paused item is active again. Because it rewrites `GuideStart`/ `GuideFinish` alongside `Start`/`Finish`, guide and playback freeze together — structurally avoiding the free-running-wall-clock desync #68 was filed about. The one gap: `TimeShift` rewrote the stored `PlayoutItem` rows but the XMLTV guide is served from a cached fragment that only `RefreshChannelData` rebuilds, and the tune-in path never enqueued it. So an external EPG client polling after a thaw could see a stale timeline until the next incidental rebuild. Fix: `IPlayoutTimeShifter.TimeShift` now returns the channel numbers whose cached guide is stale — the shifted channel plus any channels that mirror it (the same fan-out `BuildPlayoutHandler` already does) — and `TimeShiftOnDemandPlayoutHandler` enqueues a `RefreshChannelData` for each on `CancellationToken.None` (post-commit side effect must not be abandoned if the session token cancels). Tests: handler enqueues a rebuild per stale channel (+ mirror + no-shift cases); `PlayoutTimeShifter` reports source+mirrors on a shift, empty on Continuous / zero-offset / active-unforced, and correctly seeds+shifts a never-watched playout. Non-vacuity of the enqueue proven by a compiling negative control. Docs: channels.md (On-demand resume section), domain-model.md, decisions.md (scheduling.ondemand-guide-refresh-on-thaw). Per-viewer resume is out of scope (single per-channel checkpoint; #68 says per-channel suffices). fixes #68 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 19:12:42 +02:00
timothy	5985bef577	feat(525): add RemoteLogoCacher (fetch + validate + cache a logo URL)	2026-07-21 13:13:21 +02:00
timothy	65a41dbf8d	refactor(525): extract RemoteImageValidator; render path delegates to static	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	5616fa6de5	fix(511): don't let the header pre-pass break animated PNG logos ... Fourth adversarial pass cleared the security design — all three earlier bypasses are dead, DecoderOptions.MaxFrames is honored by every decoder that can produce multiple frames (GIF/WebP/TIFF exactly N, APNG N-1), and it bounds PEAK allocation, not just the final frame count (measured: 65 MiB capped vs 2.41 GiB uncapped on the same 600-frame GIF). But it caught a functional regression this PR introduced: a *default* `Image.IdentifyAsync` throws InvalidImageContentException on most APNGs that `Image.Load` reads back perfectly — including files ImageSharp's own PngEncoder wrote. Reproduced independently: 13 of 16 shapes throw, and `MaxFrames = 1` on the Identify fixes all 16 with dimensions intact. Since #502 routes ordinary channel-logo watermarks through this path, an admin with an animated PNG logo would have silently lost their watermark to a log line — a hardening change breaking working content. The existing tests could not see it: they use 64x64, which happens to be one of the few shapes a default Identify handles. Now pinned with a 288x288 shape that asserts the default Identify DOES fail and that DecodeRemoteImage decodes it anyway, in full. Also, from the same pass: - document the REAL enforced peak (up to 3x the nominal 50 MP budget, since detecting "over the limit" means decoding past it) instead of restating the nominal number. Tightening the single-frame allowance to budget/3 would reject legitimate 8K stills, so the overshoot is deliberate; it is ~600 MB against the ~36 GiB it replaces - correct the MaxFrames off-by-one claim: N-1 is APNG-specific, not universal, so the stated rationale for +2 was wrong for three of the four animated formats	2026-07-21 01:28:13 +02:00
timothy	d4e112f1e9	fix(511): bound the DECODER, not the header's frame count ... Second adversarial re-review defeated the product budget too, and the mechanism generalizes: the budget was enforced on a number the decoder does not honor. Measured on ImageSharp 3.1.12 (reproduced independently before fixing): 600-frame APNG -> Identify: FrameMetadataCollection.Count = 0 Load: Frames.Count = 600 So EnsureDecodeAffordable(w, h, 0) charged Math.Max(0,1) = 1 frame — the most permissive possible reading. A 4000x4000 x600 APNG is ~134 KiB on the wire, is charged 16 MP, and decodes to ~36 GiB: 2.5x worse than the GIF the previous commit exists to stop, at half the wire size. The retention budget could not backstop it — that runs after LoadAsync, so the process OOMs first, killing every concurrent stream. GIF, WebP and TIFF report honestly; PNG/APNG is the sole divergence, which is the point: you cannot audit every format, so the header cannot be the source of truth. DecodeRemoteImage now: - checks header DIMENSIONS only (trustworthy; a GIF image descriptor exceeding its logical screen is clamped by the decoder, verified) - derives how many frames of that size the budget affords - passes that to DecoderOptions.MaxFrames, which the DECODER enforces whatever the header claimed. Measured: MaxFrames = N yields N-1 frames, so it asks for affordable + 2 — decoding one more than allowed is what distinguishes "at the limit" from "over it" without silently truncating a legitimate animation - re-verifies the real image.Frames.Count after decoding, disposing and rejecting if over Also adds wiring coverage for the retention budget (M4): deleting its call site now fails a test — negative-controlled, build verified before trusting the result. docs/decisions.md records both failed attempts, because the lesson is the generalizable part: independent caps do not compose into a budget, and a limit the decoder does not enforce is not a limit.	2026-07-21 01:04:25 +02:00
timothy	9a2096f340	fix(511): budget decode by the PRODUCT, not by independent caps ... Adversarial re-review of the first fix defeated its decode guard with a measured payload: a 2500x2500 x600-frame GIF is ~60 KiB on the wire, passes the 50 MP dimension check (6.25 MP) AND the 600-frame check (exactly 600), and costs ~14 GiB to decode — strictly worse than the 30000x30000 PNG the guard was added to stop, at 1/60th the wire size. Checking dimensions and frames independently never bounded the decode. - decode budget is now width x height x frames <= 50 MP, as one product; a zero frame count is charged as one so an unenumerable header cannot zero it out - new retention budget: frames x scaledWidth x scaledHeight <= 200 MP. Independent of the decode budget in both directions — a 100x100 source is trivial to decode but retains ~5 GB of SKBitmap once every frame is scaled to 1920x1080, since LoadImage clones and resizes each frame to output resolution and keeps them - both budgets are pure functions (EnsureDecodeAffordable, EnsureScaledFramesAffordable) so the arithmetic is tested at every boundary without materializing multi-gigabyte images - the frame guard had NO coverage before; it does now - fail loudly on a non-seekable fetcher stream instead of letting Position throw NotSupportedException into the blanket catch - test the copy over-read against the ACTUAL rented buffer length (ArrayPool.Rent(81920) returns 131072), not the requested 81920 docs/decisions.md corrected: it claimed the byte cap bounded the decode-bomb surface and that the header check closed the class. Both overstated. An append-only file that is confidently wrong is worse than one with a gap.	2026-07-21 01:04:25 +02:00
timothy	e132c422bb	fix(511): bound remote graphics-engine image fetches ... `ImageElementBase.LoadImage` fetched http(s) images with a throwaway `new HttpClient()` + `GetStreamAsync`: no timeout override (the 100s default), no size cap, unbounded redirects, no pooling — all inside stream startup, while ffmpeg waits on the pipe. #502 routed ordinary channel-logo watermarks onto that path, widening a pre-existing weakness. Introduce `IRemoteImageFetcher` / `HttpRemoteImageFetcher`, modelled on the neighbouring `IRemoteStreamProber`: - deadline covers headers AND body (linked CTS + `CancelAfter`, client `Timeout = InfiniteTimeSpan`) — under `ResponseHeadersRead` the body read falls outside `HttpClient.Timeout` (the #289 lesson) - 10 MiB cap enforced during the copy; `Content-Length` is only a cheap early reject, since it can be absent or a lie - permissive content-type check (rejects an HTML error page, allows a missing type and octet-stream) - pooled via `IHttpClientFactory`; redirects capped at 3, not 50 A byte cap does NOT bound decoding, so `DecodeRemoteImage` additionally reads declared dimensions + frame count from the header and rejects before `Image.LoadAsync` allocates (50 MP / 600 frames). A 4 KB PNG declaring 30000x30000 costs ~3.6 GB to decode and passes every wire-size check — caught by adversarial review of the first version of this change, which capped bytes and wrongly claimed that was decode-bomb protection. Not cached and SSRF not mitigated — both deliberate, with the reasoning recorded in docs/decisions.md. fixes #511	2026-07-21 01:04:25 +02:00
timothy	381a1c2029	feat(498): add QsvPreferNativeDecoder domain field + migration (default on)	2026-07-20 21:53:16 +02:00
timothy	4aeaecb1b2	feat(67): seed shared Channel Bug watermark preset, once per database	2026-07-20 20:43:27 +02: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
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
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	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
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
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
timothyandClaude Opus 4.8	2281f2e764	fix(308): idempotent concurrent Add*ToCollection instead of a composite-PK 500 ... Two concurrent adds of the same item both membership-check it absent, both insert the CollectionItem composite key, and the loser's SaveChangesForcingVersion threw an uncaught DbUpdateException (SQLite 19 / MySQL 1062) -> 500. Now the loser is an idempotent no-op. - ConcurrencyExtensions.TrySaveChangesForcingVersion: bool-returning sibling that catches only a classified unique/PK violation and returns false. - 10 single-item Add*ToCollection handlers: return Unit.Default (no-op, skip fan-out) on false — the racing winner already inserted + rotated + rebuilt. - Bulk AddItemsToCollection: retry on a fresh context against recomputed membership so a partial-overlap collision doesn't drop the non-colliding items (bounded loop; common no-collision path runs once). - Provider detection via a TvContext.IsUniqueConstraintViolation static delegate (matches the existing IsSqlite/LastInsertedRowId provider seam), wired from Startup to SqliteErrorClassifier / MySqlErrorClassifier. - Add*ToPlaylist is NOT affected (PlaylistItem has its own identity PK; a playlist may legitimately contain the same item more than once). Tests: a negative-control anchor proves the race genuinely throws a classified exception; end-to-end handler tests reproduce a real cross-connection race via a shared-cache SQLite harness + a SavingChanges interceptor (the single-conn in-memory fixture cannot). Every fix-dependent test verified to fail with the catch disabled. Docs: api-conventions.md §7a (idempotent insert under concurrency) + decisions/optimistic-concurrency.md. fixes #308 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 13:02:14 +02:00
timothyandClaude Opus 4.8	e364b338e6	feat(425): per-source rotation weights + query corrections for auto-tune channels ... Auto-tune channels can now carry per-content-source rotation weights (weighted round-robin, e.g. 3x Show A / 1x Show B) and query corrections (exclude / add-untagged), supplied at bulk-create time via an optional `sources: [{sourceId, weight, excluded}]` on each AutoTunedChannelRequest. Design (Option A, reuse #70): when a source is customized the channel is backed by a system-owned MultiCollection of per-source SmartCollections carrying the weights, with PlaybackOrder.WeightedShuffle -- the exact path WeightedShuffleCollectionEnumerator already consumes. All-default weights keep the #69 single-SmartCollection fair-share shape. - Discriminators: TV -> live show_title:"X" (episodes carry no parent-show id in the index); movies -> stable id:{mediaItemId}. - Materialization is axis-dependent: TV materializes every base show individually (un-weighted shows keep per-show fair-share) + a live remainder at weight 1; MovieGenre materializes only touched movies + one count-weighted remainder. - Remainder = (base) AND NOT (materialized union excluded) -- a partition. - New nullable OwnedByChannelId on SmartCollection + MultiCollection (dual-provider migration); owned rows are hidden from the collection lists and cascade-cleaned on channel delete. Tests: AutoTuneAxisMap query/partition units; DB-backed weighted-path handler tests (TV materialize-all, movie count-remainder, exclusion, no-customization fallback); delete-cleanup. Docs: decisions.md, domain-model.md, api-conventions.md; OpenAPI trio regenerated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 03:52:06 +02:00
timothyandClaude Opus 4.8	ed6c43065f	feat(164): guided remediation for health checks (server-declared {Kind, Target}) ... Make the ~14 health checks actionable: each check that has a fix now declares where to go, and the SPA acts on it. Backend: - Widen domain HealthCheckLink (string Link) -> (string Target, HealthCheckLinkKind Kind) with ExternalDoc|AppRoute + factories; only the 4 link-building checks and the API mapper touched .Link. - Evolve HealthCheckResponseModel additively (/api/v1 frozen-additive): keep deprecated string? Link (still populated), add Brief (the BriefMessage the mapper was silently dropping) and nested Remediation {Kind, Target}. Kind is a mapped string, not a wire enum. - Make Mapper.GetStatus total: NotApplicable no longer throws (defensive; handler still filters it). InternalsVisibleTo(ErsatzTV.Tests) added to unit-test totality. - Fix 2 stale Blazor route links (media/trash -> /app/trash, search?query -> /app/search); add AppRoute remediation to actionable checks that had none (libraries / schedules / ffmpeg-profiles / settings). SPA: - DashboardScreen health panel renders remediation: AppRoute -> client-side nav button, ExternalDoc -> new-tab anchor; detail text truncates with title-hover. - Remove the dead "Open Classic UI" -> /system/health row from SettingsScreen (a #91b leftover that just 302'd to /app); update its regression test. Docs: decisions.md (#164), api-conventions.md (deprecate-in-place DTO evolution), blazor-route-parity.md (Section 4 correction); v1.json/v1.d.ts/endpoint-index regenerated. fixes #164 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 00:51:40 +02:00
3 people	9752111240	docs(70): fix the last stale claim — found by reading every weight comment, not by grepping verbs ... Round-4 review returned BLOCKED, and its diagnosis is the sharpest of the four: my "re-derived by grep" claim was false. The reviewer's grep included `dropped`; mine had `drop(ped)? every` and missed the bare word — so MultiCollectionConfiguration.cs:38 ("a 0-weight source is dropped by the enumerator") never matched. That is the same failure as the previous round, one level up: I replaced a list of SITES with a list of VERBS I guessed and called it a class. Fourth consecutive incomplete completeness claim, and again the code twin of a doc line I had already corrected. The site is now accurate. The DB default of 1 is still right, but for the reason decisions.md already gives: a 0 backfill means nothing on a share-of-airtime scale. The enumerator clamps such a row to the floor, so it rotates rather than vanishing -- the drop it cited cannot happen since EffectiveWeight replaced the Weight > 0 filter, and A_Non_Positive_Weight_Does_Not_Delete_The_Source pins that. Method changed, not just the text: instead of guessing which verb a stale claim might use, enumerate EVERY comment/doc line mentioning weight across the diff and read them. 41 lines, one false. Both automated passes then produced false positives on different subjects -- a line-based check flagged EffectiveWeight's "must not drop..." (the framing verb wraps to the previous line), and a sentence-aware one flagged ReplacePlaylistItemsHandler's "the item is dropped from the playlist" (true, and about unknown ORDERS, not weights: PlaylistEnumerator really has 0 default arms and gates on `enumerator is not null` at :210). Both were read and cleared rather than counted, which is the only reason this message can say what it says. Verification: Build 0 errors; Core.Tests 566; ErsatzTV.Tests 1673; 0 failed; no BOM on any touched non-generated .cs; decisions-guard exit 0. Refs #70 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 17:00:46 +00:00
3 people	0295a8a9f6	style(70): strip UTF-8 BOM from the .cs files this PR touches ... CI's Formatting job failed: 19 touched files carried a BOM, which .editorconfig forbids (charset=utf-8). Pure encoding change — one byte per file, no semantic diff (verified: every hunk is `-namespace` -> `+namespace`). Self-inflicted. The patches that edited these legacy files wrote them back as utf-8-sig to "preserve the existing style", but the #311 fix-as-you-touch gate requires a file to be normalized when you touch it — that is the whole point of scoping the gate to changed files instead of reformatting the ~2500 legacy BOM files at once. dotnet format leaves the EF-generated Designer/snapshot files alone as generated code, and its verify skips them the same way, so they stay as ef emitted them. Two corrections to what I believed going in: - `dotnet format --include` does NOT no-op here. It reported `error CHARSET` for each file and exit 2, reproducing CI exactly, and fixed them in place. The note claiming otherwise is wrong for this invocation. - My first BOM check reported all files clean. The od pattern was wrong; reading the first three bytes directly found 19. A detector that can only say "ok" is worse than no detector. Core.Tests 565, ErsatzTV.Tests 1673, Architecture.Tests 5 — all passed. API artifacts still in sync. Refs #70 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 17:00:46 +00:00
3 people	68be319403	feat(70): WeightedShuffle playback order — weighted / fair-share distribution ... Adds PlaybackOrder.WeightedShuffle = 9 (Classic engine only) plus the per-source weight it distributes by. Why a new order rather than making ShuffleInOrder weight-aware: ShuffleInOrder's balanced shuffle pads sources to equal length with Option.None spacers, and spacers emit nothing — so one cycle plays every item exactly once and airtime stays proportional to collection size. It prevents *clumping*, not *domination*. Retrofitting weights onto it would silently change shipped users' output. WeightedShuffleCollectionEnumerator picks a source by smooth weighted round-robin (acc += weight; richest wins; pays the total), then takes that source's next item. Weights 3:1 emit A A B A; ties break to the earliest source in list order. Fair-share is the equal-weights default, so one mechanism covers both behaviors in the issue. One rotation is sized so the source needing the most picks works through all its items at its share; smaller sources loop within it — that looping is what makes equal weights mean equal airtime regardless of library size. The sequence stays a pure function of (Seed, Index), so it restores by replay like its siblings and needs no per-source persisted counters. It consumes ShuffleSourceBuilder.GetCollectionItemsForShuffleInOrder unchanged — the schedule-entity-free entry point #380 reserved for this issue. Source identity is destroyed on the Shuffle path (MultiCollectionGrouper collapses to GroupedMediaItem + Distinct), so the weight is only reachable via CollectionWithItems on the ShuffleInOrder-shaped path. Weight is persisted on MultiCollectionItem AND MultiCollectionSmartItem — the mirror is mandatory; omitting the smart item silently un-weights smart-collection members. Both carry a DB default of 1: without it existing rows would migrate to 0, and a 0-weight source is dropped by the enumerator. Refs #70 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 17:00:46 +00:00
timothy	1e35248edf	style(72): de-BOM the six touched .cs files (#311 formatting gate) ... CI's "Formatting (changed .cs conform to .editorconfig)" job failed with `error CHARSET: Fix file encoding` on all six pre-existing BOM'd files this PR touches. The #311 gate is fix-as-you-touch: any .cs a PR touches must conform to .editorconfig (charset=utf-8), and these carried BOMs inherited from upstream. BOM removal only — six files, one line each, zero content change. The three files already without a BOM (GetChannelByIdForApiHandler + both new/changed Tests files) needed nothing. Note for the next person: this cannot be validated locally on this Mac — `dotnet format --include` silently no-ops here, so the gate is only observable in CI. Check `head -c3 <file> | xxd -p` for `efbbbf` on every touched .cs before pushing instead of trusting a local format run. Refs #72	2026-07-17 17:51:43 +02:00