57 lines
3.9 KiB
Markdown
57 lines
3.9 KiB
Markdown
# 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.
|