gramps
d95a23c6fb
Correcting the handoff against the repo, per the rule that a stale map is worse than no map. Three facts were wrong or missing, and the first two would have made the next session's first action wrong. 1. PUSH STATE. "Last pushed: e7cded6" with two commits listed as unpushed. main was actually 9 commits ahead of origin/main. The line under-reported unpushed work by 7 commits, which is the optimistic-by-construction failure MyMistakes.md already names for a handoff whose heading promises the work is live. Now recorded as caught up. 2. TASK 50 WAS ABSENT, AND IT CARRIES A LIVE BUG, NOT A QUEUE ITEM. The task was carved 2026-09-28 and its mechanism section was CORRECTED the same day against the creator's own channel: 20+ private videos, all content-less placeholders. That is not a deferred feature, it is the real explanation of the 2026-09-26 "I cannot get private test recordings saved" report the map had been carrying as a closed item. liveBroadcasts.insert succeeds and creates the placeholder; the RTMP push / LIVE transition / archive chain is what fails, so no video content is ever produced. Added as an OPEN entry with the single diagnostic question that localises it (does ffmpeg reach a.rtmp.youtube.com, and does the broadcast reach LIVE), plus the sequencing constraint: do NOT flip enableAutomaticArchiving before TASK 50 ships, since archiving is currently the only route a recording takes to YouTube. It also carries an open 11.12 re-check — a publish feature makes the app PUSH creator content to a third party, so the IARC answers must not describe an app that cannot publish. That is a certification-ordering constraint, not a code detail, and it belongs where the next session will read it. 3. TEST COUNT WAS STALE. Recorded 379; the suite is 380 (the force-ssl scope test added one). Re-verified on a clean test-project build. Also recorded a new flake honestly rather than leaving it for the next session to rediscover as a regression: MasterLimiter_CapsTheLiveMix_OnThePipe failed once on a full-suite run with Expected 0.891 / Actual 0, then passed 27/27 as a class run and 380/380 on an immediate re-run. It reads the live mix off the named pipe, so a ZERO is the pipe not being fed yet, not the limiter misbehaving — the same whole-suite scheduling family as the RealAppHost STA landmine. Recorded with "re-run before believing it". Next list: the RTMP diagnostic sorts first because it is an observation rather than a build and it gates a queued task; the packaging unit remains the next CODE unit, which is not a reordering of the creator's priorities. verify.sh: clean build, 0 warnings, 380/380, scope check passed.
ytLlive
A creator-proof live-streaming and recording app for YouTube — native Windows (C# / WPF / .NET 8).
Screenshot
Design Principle
This software is so intuitive that even the most right-brained person can easily intuit and use it.
Every feature is measured against this. One-click go-live, sane YouTube defaults, visual scene building, and no dead ends — every action has a visible outcome.
Why ytLlive
OBS treats YouTube as an afterthought; SLOBS is Twitch-first with YouTube bolted on. ytLlive is designed and dedicated to YouTube livestreaming and recording, and to YouTube's specific quirks.
Account Assumption
ytLlive assumes you already have a YouTube creator account — connecting uses "Sign in with Google" to link that existing account. ytLlive does not create accounts. If you don't have a YouTube channel yet, set one up on YouTube first, then connect it here.
Audio Assumption
ytLlive uses your default microphone and desktop/game output — it never hunts for a device or contends for one. It assumes your audio is already configured and working (default input and output set, not hijacked by another app). Audio issues are a Windows/device matter outside ytLlive's scope: we don't debug, detect, or try to fix them. If it doesn't sound right, fix the system's audio settings first — it's on the OS, not on us.
Run
dotnet build # Windows only — WPF
dotnet run
Version Roadmap
v1 is the finished product (creator ruling, 2026-09-01 — there are no v1.x releases).
Everything still queueing lands in v1; anything not on the feature list is on the closed
"Out of product — permanently" list in TASKS.md — read that page before asking for a feature.
What v1 ships: the five-scene director's control surface, webcam + screen capture, media + web + text sources, chat on-stream, the social bar, mic/desktop audio with auto-duck and TRAX, local recording, variable quality tiers with auto step-down, one-click go-live + scheduling, stream resilience (auto-reconnect inside YouTube's grace, one-click back on air), built-in monetization awareness (reward capture, session reports, YPP journey tracker), Alerts — all free and ungated; the one-time license only removes the branding flash.
Structure
| Path | Role |
|---|---|
Models/ |
Scene, Source, WebcamSceneConfig, SceneElement, SceneCatalog, QualityOption, StreamConfig/Health, chat, Socials, BroadcastMetadata, Music, MicStatus |
ViewModels/ |
MainViewModel (partial classes per area) + dialogs: GoLive, CameraPicker, MicPicker, HotkeyConfig, Socials, LiveBroadcastForm |
Services/ |
YouTube (OAuth, streams/broadcasts, chat polling), LayoutStore (SQLite), capture (camera/screen-capture/media-file via FFmpeg), SceneCompositor + FramePump, FFmpeg encoder + RTMP, audio pipeline (WASAPI loopback + mic, mixer, filters, ducker, limiter, TRAX), SocialValidator, notifications, hotkeys, SceneGraph, ChatOverlayLayer |
Helpers/ |
ViewModelBase, RelayCommand, ImageCache, AppLog, TokenStore (DPAPI), OAuthCredentials, converters |
Themes/ |
Controls.xaml — the dark-theme control styles, merged once in App.xaml |
MainWindow.xaml |
Dark-theme control surface: thumbnails + central preview, two-state left panel (layers/properties ↔ live chat), top bar, footer |
Distribution.md |
GA-time plan: signing, installer, EULA, hardening — executed as TASK 36 |
Docs (memory map)
schema.md defines the conventions; ai.md is the AI/session guide;
TASKS.md is the task queue. Each code directory carries an index.md.