# Bugs

## 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.