a9eb360288
Encoder dual-output: StreamEnabled/RecordEnabled/RecordPath options; per-output ffmpeg block (stream ->flv, record ->mp4); throw unless at least one output. RecordingFile: auto-name ty-<yyyymmdd>-<start hhmm>-0000.mp4, rename-on-stop to ty-...-<len hhmmss>.mp4 with numeric-suffix on collision. LayoutStore persists record folder. MainViewModel: REC/ON-AIR pills, status light, single Start<->End button (replaces Start/Stop variants), StopStream no longer signs out, explicit session timer. About overlay widened. Sign In label + spacing before Start. Tests: 244 passed / 246 (2 pre-existing: AudioPipeline gains-mute, RoundClip). Build 0 warnings. Scope check clean. Memory-map correction (derived-solution rule, 2026-08-29): image-shrink recipe was never recorded when first done, so it was re-derived. Added Derived-solution/recipes rule to AGENTS.md; MyMistakes.md now a permanent recipes registry (records the verified WPF-imaging shrink recipe); schema.md rows MyMistakes as registry; ai.md points to the rule. README hero image replaced: 3.2MB screenshot -> 1400x794 -> 188KB docs/ytLlive-preview.jpg (JPEG q82).
2.3 KiB
2.3 KiB
MyMistakes.md
Two jobs, distinguished by heading:
- Per-task failure log — updated before every commit touching that task: current iteration + why the last one failed. On task complete, committed AND pushed → truncate to this stub. A new task does NOT seed this file until its first failure.
- Recipes registry (DERIVED-SOLUTION RULE, see
AGENTS.md🔬) — the durable home for one-off derived solutions, recipes, and how-tos. The moment you work out a reusable solution, write it here in the same session. GREP THIS FILE FIRST when you hit a "I've done this before but have to figure it out again" wall. Recipe entries stay permanently (they are NOT truncated on task completion) — only the failure log truncates.
🔬 Recipes registry
Shrink / re-encode an image for the README (screenshots → small hero image)
Worked out 2026-08-29 (the recipe was NEVER recorded the first time it was done, so it had to be re-derived from scratch — that's the incident this entry exists to end).
Approach: a throwaway Windows-dotnet console app uses WPF's imaging stack
(System.Windows.Media.Imaging) — same framework the app runs on, zero NuGet
packages, high-quality downscale via TransformedBitmap. Screenshots compress
far smaller as JPEG than PNG (PNG 1400px = ~1.2MB; JPEG q82 1400px = ~188KB).
Recipe (run via the Windows dotnet host from WSL):
- Create
imgresize.csprojtargetingnet8.0-windowswith<UseWPF>true</UseWPF>(SDK controller). Put it in a Windows-visible temp path, e.g.C:\Users\gramp\AppData\Local\Temp\imgresize— NOT/tmp(Windows dotnet can't reach a Linux-only path reliably). Program.cs: loadBitmapImage(CacheOption=OnLoad→Freeze()), downscale withTransformedBitmap(src, new ScaleTransform(scale, scale))to max width (1400 for the README hero), encode withJpegBitmapEncoder { QualityLevel = 82 }, save.- Run:
"/mnt/c/Program Files/dotnet/dotnet.exe" run -c Release --project .
-- "C:\Users\gramp\Downloads\Screenshot 2026-08-29 075626.png"
"C:\Users\gramp\Documents\Code\projects\ytLive\docs\ytLlive-preview.jpg" 1400
- Point
README.mdat the.jpg(not.png).
Result: 3.2MB screenshot → 1400×794 → 188KB ytLlive-preview.jpg in docs/.