# HANDOFF — 2026-09-15 (webcam take fix 1 of 2 committed locally; slice-18 already local — verify both)

## Branch / Commit State

`main` HEAD = **webcam reader-ladder fix** (committed LOCALLY with this handoff, NOT pushed — web/A/V
work stays commit-local until greenlight). Below it: **slice-18 C4 composite cache** (also local, un-pushed),
slice-17 overlapping capture readbacks, slice-16 capture conversion fix, slice-15 pacing fix, `c01206f`
(composition capture), `b22d08e` (signed audio-sync, pushed). Working tree clean.

## ⚠️ Branding (2026-09-14, creator-corrected): product = **llamacasty**, internals = ytLive

The product is **llamacasty**; repo path, csproj `AssemblyName`/`RootNamespace`, DB/log paths
(`%APPDATA%\ytLlive\...`), and most code names are the legacy **ytLive/ytLlive**. User-facing
language says "llamacasty"; code/assembly/repo names stay ytLive. See `ai.md` → Brand.

## ✅ Committed locally — webcam take fix 1 of 2: reader-output-subtype ladder

**Incident (2026-09-15):** browser (msedge) grabbed the C920 → app died silently (last log line
09:16:47 is the `MediaCapture.Failed` "device no longer present" rollback; then nothing — no
AppDomain/Dispatcher handler fired → native WMF death). Fresh launches then showed NO webcam:
`CameraManager: camera '…GLOBAL' failed: '… frame reader refused to start: OutputFormatNotSupported'`.

**Diagnosis (startup.log, four sessions):** the camera's live media type is the variable. Under
msedge + NVIDIA Broadcast contention our `SetMediaStreamPropertiesAsync` refuses ("file is being used
by another process / CaptureMode is SharedReadOnly") so the camera keeps whoever's format: YUY2 640x480
@07:47-08:52 → reader started fine (starved of frames while they held it; worked at 08:52 when they
didn't); **MJPG 1920x1080 @19:01/19:05 → `CreateFrameReaderAsync(.., Bgra8)` + `StartAsync` refused
with OutputFormatNotSupported** (MS-documented: an MJPG-active source can't be read as Bgra8 by a
MediaFrameReader — it exposes NV12; the MJPG→BGRA converter isn't on the reader pipeline).

**Fix** (`Services/MediaCaptureFrameSource.cs`): reader creation is now a per-candidate ladder —
`ReaderSubtypeCandidates(activeSubtype)`: Bgra8 for uncompressed cameras (unchanged fast path);
**NV12 then source-default for MJPG** (converted in `OnFrameArrived`, which already handled non-BGRA).
Each candidate is allocated AND started under its **own catch** — WinRT answers an unsupported subtype
with a THROW (`E_INVALIDARG`), not a status; the throw degrades to the next candidate instead of
aborting acquisition (creator rule: WINRT resource-allocation calls wrap per-call; see
`MyMistakes.md`). Rejections are logged + joined into the final error.

**Good Dog tests:** `ytLive.Tests/MediaCaptureFrameSourceTests.cs` x4 — MJPG never asked as Bgra8,
case-insensitive, uncompressed keeps Bgra8 fast path, unknown/null → Bgra8. **301/301 green, clean
build 0 warnings, scope-check passed** (2 code files + ai.md + HANDOFF + MyMistakes).

## ⚠️ Open items

- **Webcam take fix 2 of 2 — the 09:16 crash is UNFIXED (hard, untested):** hypothesis — the app died
  natively (no managed log line) when `MediaCapture.Failed` fired mid-stream: RollbackSession runs
  `_ = SafeStopAsync` fire-and-forget → `StopAsync` disposes reader+capture while the frame-reader
  thread is mid-`TryAcquireLatestFrame`/`Marshal.Copy` (that call region sits OUTSIDE the frame's
  try/catch). Managed/unwrapped failures there surface via AppDomain handler (absent → native AV).
  NOT fixed in this change: no repro, no integration test, and a native WMF race isn't catchable --
  deferred per spin-guard. Record if a second occurrence shows a pattern.
- **Can't re-add webcam (3rd symptom):** partly the same root cause (add → AcquireAsync fails → empty
  chip + toast). Note: if ANOTHER scene still holds a WebcamSceneConfig, `_webcam != null` persists and
  "Add → Webcam" stays disabled by the single-identity rule — use right-click "Show Webcam" instead.
- **Device re-verify (two things, same take session):**
  1. slice-18 cache (unchanged verdict criteria): `cache NR/WH` hits dominate on TV holds, stalls gone,
     band fresh updates/s toward ~60 → else residual 24↔60 pulldown, content decision.
  2. webcam ladder: while msedge holds the camera, a fresh launch must show the webcam (or degrade to
     a clear chip, never a silent box); after closing the browser it must come up at 1080p30 MJPEG.
- **No push yet** — after the take verdict, re-measure the clap offset (`/tmp/opencode/avsync.py`),
  then decide push with the user.

## Open threads (carried)

- Audio-silence verification — fixed (`724af14`); creator heard real audio.
- Webcam MJPG missing / ~10–14Hz, layer SortOrder, truncation-with-dynamic-scenes — queued.
- Sync control user-doc tutorial — REQUIRED before 1.0 (creator directive; TASK 22).
- Signed A/V sync: verify the negative (advance) direction on device.
- Focus-loss capture lag — closed as NOT the cause (1824: delivery healthy ~60-100/s).

## Landmines

- testhost shares startup.log — filter by time; the app also writes fake-device failures
  ('test-camera', 'dev-physical-9') from the CameraManager unit tests.
- `cmd.exe /c "taskkill /F /IM ytLive.exe"` (WSL double-slashes mangle) before rebuilds — a live
  app process locks `ytLive.exe` and the apphost copy fails (MSB3021).
- Build/tests: **Windows dotnet host** (`/mnt/c/Program Files/dotnet/dotnet.exe`). 0 warnings —
  only `./scripts/verify.sh "<files>"`'s clean build counts. Building `ytLive.csproj` alone does
  NOT rebuild `ytLive.Tests.dll` — run the Tests csproj before `vstest`. Known audio flake:
  `Mix_HonorsProviderGains_AndGameMute_KillsTheLoopback` (float precision) — re-run if it trips
  alone; it is unrelated to camera work.
- Camera contention failure modes (startup.log): "no frames within 4s" = init OK but starved;
  "OutputFormatNotSupported" = reader subtype below the MJPG-active camera; "file is being used by
  another process / CaptureMode is SharedReadOnly" = our stream re-negotiation refused while others
  hold the device. CameraConflictProbe lists named processes that are merely RUNNING (msedge,
  NVIDIA Broadcast) — a suspect list, not handle evidence.
- FramePump tests that assert per-frame CONTENT must pass a STABLE scene (`() => scene`) — the
  default NewPump scene is fresh-per-tick (ok for pacing tests, but it churns the C4 render
  signature and hides the cache). Cache-sensitive assertions also can't use a call-count resolver
  flip (the tick resolves twice: signature + render) — key alternation on `OutputIndex`.
- ffmpeg/ffprobe: `/mnt/c/Program Files/Krita (x64)/bin/` with Windows paths.
- `MyMistakes.md` has the WINRT resource-allocation RECIPE (new), freeze-audit RECIPE, A/V sync
  measurement recipe, deadline-pacing lessons, CoreMessaging DQ recipe, WGC-CLIP + slice blocks —
  grep before re-deriving. ai.md has the webcam reader-ladder note.
- sqlite3 at `/home/gramps/android-sdk/platform-tools/sqlite3`.
- `C:\tmpout` is for ffmpeg evidence artifacts (raw decodes / PNGs); keep them out of the repo.

## Next step

Creator records a take on this build (backend test): (a) with the browser holding the camera — fresh
launch must show the webcam or a named chip, then (b) close the browser and re-add the webcam to the
live view — must come back at 1080p30 MJPEG; (c) the slice-18 cache verdicts from the same session
(`cache NR/WH` hits, stall frequency, band audit). If (b) works: measure clap offset, decide push.