Files

T

gramps e2ecc248e0 TASK 47: draw the alert clip — the preview Image was Collapsed for AlertBox

Four builds (89/90 + two) burned proving the alert video was PERFECT: real h264
1280x720, 240 frames decoded, alert audio in the live mix, and the shipped asset
byte-identical (md5 0ee1f496…) to the creator's llamacasty-dancingLlama-thankyou.mp4
with every sampled frame full bright content. Build 90's new diagnostics then showed
the frame reaching BOTH consumers every second for the whole clip —
`Alert preview: frame=680x200 a255` and `Output resolver: frame 680x200
playing=True` — an opaque, correctly-sized frame, handed over and never seen.

Root cause: Controls/PreviewPane.xaml keeps the per-element Image Collapsed unless a
DataTrigger fires, and there was no IsAlertBox trigger (only IsImageSource / IsChatBox /
IsWebSource / IsWebcam). The alert box's Image was therefore Collapsed forever. Chat
boxes rendered because they HAVE a trigger — that asymmetry is the whole clue, and it
is why removing/re-adding the layer could never fix it.

Fix: an IsAlertBox DataTrigger beside the IsChatBox one.

Two Good Dog tests, because the existing fakes had been hiding this:
- AlertBoxPreviewVisibilityTests (red `Expected: Visible / Actual: Collapsed`, now
green) drives the real MainWindow + PreviewPane and asserts the bound Image is
Visible — the first alert test that crosses the XAML at all.
- AlertClipOutputTests is the first test in the repo to run a REAL codec: pinned ffmpeg
generates a clip, the real AlertClipDecoder + AlertOverlayLayer + SceneCompositor
composite it, and the box rect must be a colourful picture that DIFFERS from idle. It
passed while the feature was broken in the app — which is exactly why it was needed:
it exonerated decode+layer+compositor and pointed the hunt at the last hop.

Also keeps the two once-per-second alert diagnostics (resolver + preview) that settled
it, pending the creator's call on whether to keep them.

Notes: the pinned BtbN ffmpeg has no libx264, so the test clip is -c:v mpeg4.
SceneCompositor.Render fills its base with opaque black, so the test compares against an
idle render rather than counting non-zero bytes. MediaSource has the same missing trigger
in PreviewPane.xaml — left unfixed as out of scope, noted in HANDOFF.

Full suite 324/324. Lesson recorded in MyMistakes.md rule (5): a producer that hands over
a correct frame has still delivered nothing — when output arrives and the user still sees
nothing, stop auditing the producer and audit the consumer's VISIBILITY.

2026-09-26 14:44:57 -07:00

4.3 KiB

Raw Blame History

HANDOFF — 2026-09-26, end of session

Where we are

main, 5 local commits ahead of origin/main (= ecb329e), NOTHING PUSHED. Last pushed commit is still ecb329e. Do not push without the creator saying so.

commit	what
`a11b15e`	TASK 47 alert video (first landing)
`7b940b6`	poller-thread marshal crash fix
`80038ff`	silent-decoder fallback + diagnostics
`aea0670`	video pacing via `FfmpegFrameRateProbe`
(last, unpushed)	the real alert fix: `PreviewPane.xaml` `IsAlertBox` trigger + 2 Good Dog tests + resolver/preview diagnostics

THE ANSWER (do not re-derive this)

The alert video was never drawn, never mis-decoded. Build 90's diagnostics showed Alert preview: frame=680x200 a255 and Output resolver: frame 680x200 playing=True every second for the whole clip — a real, opaque, correctly-sized frame reaching BOTH consumers. Controls/PreviewPane.xaml keeps the per-element Image Collapsed unless a DataTrigger fires, and there was no IsAlertBox trigger (only IsImageSource / IsChatBox / IsWebSource / IsWebcam). Chat boxes rendered; alert boxes never could. Removing/re-adding the layer could not have fixed it.

Clip itself is fine: DB asset 941785b0-d022-45fa-a8a2-2cd59ae2ba48 is byte-identical (md5 0ee1f4960dd3b23dee5930a2af79d410) to the creator's C:\Users\gramp\Downloads\llamacasty-dancingLlama-thankyou.mp4 — h264 1280x720 10s, every sampled frame full bright content.

Working tree

Clean apart from the uncommitted work unit above (it is committed; check git status). If the app is running, ytLive.dll/.exe are LOCKED and any build fails with MSB3021/ MSB3027 — the creator must close ytLive first. That is normal, not a broken build.

Build / test commands (Windows host, always)

"/mnt/c/Program Files/dotnet/dotnet.exe" build "C:\Users\gramp\Documents\Code\projects\ytLive\ytLive.csproj" --no-restore
"/mnt/c/Program Files/dotnet/dotnet.exe" vstest "C:\Users\gramp\Documents\Code\projects\ytLive\ytLive.Tests\bin\Debug\net8.0-windows10.0.19041.0\ytLive.Tests.dll"

Last full suite: 324/324 pass. Run it with ytLive CLOSED or the RealMouseDrag env flake fires.

Queued next (creator's words, 2026-09-26) — the Good Dog queue

Test-console chat must not clear the chat window. "when I add a chat message from the test console, or from any console, that chat text should not clear the current chat window."
Test pull-out chat input: 20px right padding — the text box is clipped at the right edge of the div; needs 20px padding against the div's right side.
Test pull-out chat input: Enter inserts a newline, it must not send.
Verify the alert video live on the next build (the fix is in; nobody has SEEN it play yet). This is the confirmation step for the commit above.

Landmines / facts worth keeping

The pinned BtbN ffmpeg has no libx264 — generate test clips with -c:v mpeg4.
SceneCompositor.Render fills its base with opaque black, so "any non-zero byte" is not proof a layer painted. Compare against an idle render, or count COLOURFUL px.
sqlite3 on WSL: /home/gramps/android-sdk/platform-tools/sqlite3. Extract a BLOB with SELECT writefile('/tmp/opencode/x.bin', Data) FROM Asset WHERE Id='…' (Linux paths only — a C:/… path creates a junk C: dir IN THE REPO; one was made and removed).
Layout DB: /mnt/c/Users/gramp/AppData/Roaming/ytLlive/ytLlive.db (tables: Asset Id/Hash/Data, Settings, Source, Scene, …). Alert default video setting key: AlertDefaultVideoAssetId. ffmpeg/ffprobe live in /mnt/c/Users/gramp/AppData/Roaming/ytLlive/tools/ (run the .exe directly from WSL).
Two diagnostics were ADDED and are still in the tree (once-per-second, alert only): Output resolver: alert box … (MainViewModel.cs) and Alert preview: box … (AlertOverlayLayer.cs). Decide with the creator whether to keep them or strip them now that the root cause is known.
PreviewPane.xaml has the same latent gap for IsMediaSource (no trigger either) — NOT fixed (out of scope), noted as a follow-up.
Known perf item, untouched: FramePump stalls ~140-180ms renders (render=full-render split=0 … totalMs=140). Unrelated to the alert bug.
YouTube rejects the complete transition (403) at end-of-stream; enableAutoStop finishes the broadcast. Harmless, already handled.

4.3 KiB Raw Blame History