3.9 KiB
Bugs
Scene strip tile + on-air artwork assets deleted on the next Save (FIXED 2026-10-10)
The scene tiles and the shared on-air image are stored as Asset-table BLOBs (per-scene
Scene.ThumbnailAssetId + the OnAirImageAssetId Setting). LayoutStore.Save() runs an Asset
pruner that only keeps rows referenced by Source, the alert clip setting, and — after the fix —
the two new references: it DELETE FROM Asset WHERE Id NOT IN (SELECT ThumbnailAssetId FROM Scene …, SELECT Value FROM Settings WHERE Key = 'OnAirImageAssetId'). Without that, the very first save after
seeding would have wiped the freshly-imported tile art, and every tile would have silently fallen
back to the scene's background until the next launch re-seeded it.
Scene strip / F-keys out of sequence (FIXED 2026-10-10)
Report: "the ordering of the 5 screens and their corresponding F-key is out of sequence." The strip
renders Scenes ORDER BY SortOrder but each tab's F-key label is name-derived, so the two can drift
when a session persists a non-canonical order (on the creator's DB: Chat SortOrder 2, BRB 3 — tabs
showed "Chat F4" then "BRB F3").
Fix (same commit): MainViewModel.LoadLayout calls the new
ReorderScenesToCanonical() after loading — the five canonical scenes render in F-key order
(Starting, Live, BRB, Chat, Ending = F1-F5), renamed (non-canonical) scenes keep their loaded order
after them; the next auto-save re-stamps SortOrder to the corrected index. One integration test
(SceneOrderTests) seeds a Chat-before-BRB DB and asserts the loaded order + F1-F5 labels, then that
a save persists the corrected SortOrder (fresh load keeps canonical order).
Desktop "locked" after the app starts while a fullscreen game is running (FIXED 2026-10-10)
Report: once the app is started, the desktop is "locked" — the mouse can no longer interact with it — which made streaming live gameplay impossible.
Root cause: at launch the main window activates (WPF default ShowActivated=true). If the creator
is already playing an exclusive-fullscreen game (e.g. THE DIVISION 2 while starting a gameplay stream),
activating LlamaCasty makes Windows drop that game to the taskbar; the app's 1920×1040 window then sits
over the whole work area, so the desktop looks locked and the game can't be reached with the mouse.
Fix (same commit as this entry): the window no longer steals focus when a full-screen game owns the
foreground at launch — MainWindow.xaml.cs ctor sets ShowActivated = !_viewModel.FullscreenGameRunningNow,
and the new MainViewModel.FullscreenGameRunningNow (initially added in MainViewModel.Background.cs)
wraps GetForegroundFullScreenMonitorIndex() != null. Result: opening the app while in-game leaves the
game focused and alive; opening it normally behaves exactly as before.
Verification: build clean (0 warnings). Real-app reproduction/test launch deferred until the creator is off-mouse — the real-mouse + fullscreen-detector tests must not run while a game owns the screen.
iTunes music showing on mic meter
Playing music via iTunes causes the mic meter to show audio levels. The WASAPI
mic capture (DataFlow.Capture) and loopback capture (DataFlow.Loopback) are
separate devices. If iTunes audio appears on the mic meter, it is likely acoustic
coupling — the mic picking up speaker/headphone output. Verify by muting the mic;
if the meter still shows levels, check Windows Sound settings for stereo mix or
"listen to this device" routing.
Live recording ≠ "recording results" shown in Chat view (NOTE ONLY — no fix)
User note (2026-09-14): the recording produced while live is completely different from the "recording results" surfaced in the Chat view. Do NOT attempt to fix or reconcile them pre-1.0 — this entry exists so the discrepancy is never rediscovered as a surprise. When the reconciliation work is eventually queued, start by mapping both recording paths side by side.