3 Commits

Include renames

Author	SHA1	Message	Date
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	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	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