Release notes
Videorc 0.9.79 Beta 1
Under output pressure the recorder used to throw away frames it had already encoded — the reported case reached a full queue with the oldest frame more than half a second late. It now protects every encoded frame and sheds only work it has not done yet, stopping only after a genuine stall. Live controls also stop getting stuck: switching scenes, screens, captions or chat now reconciles against what the backend actually did instead of blindly replaying a command whose outcome was unknown.
Live controls keep up, and recordings keep every frame
- Recordings under heavy load no longer lose frames that were already encoded — only unrendered work is skipped, and only while real progress continues.
- Scene, screen, caption, chat and takeover changes no longer stick or double-apply when a command's outcome was unclear; they reconcile against the backend's real state.
- Backend commands run in separate lanes, so a slow chat or account request can no longer delay going live or stopping a recording.
- Recording and streaming get their own encoder roles where supported, with per-role diagnostics reset between sessions and stale files cleaned up safely.
Fixed
- Encoded frames survive output pressure. The bridge shed whole access units when the output queue filled, so a burst of downstream pressure cost finished work. It now preserves every encoded access unit and drops only unencoded compositor ticks, and it stops only after a bounded no-progress stall rather than at the first sign of pressure. Includes exact regression coverage for the reported incident (queue depth 16/16, oldest frame 528 ms against a 250 ms budget).
- Live-control stalls. Backend commands are split into explicit observation, account, chat, live-control and stop lanes with reconnect-safe ordering, so one slow lane cannot block another. Mutations whose outcome was unknown — screen, scene, caption, chat, takeover — are reconciled against authoritative backend state instead of replayed.
- Hardened account-refresh generations, screen-activation persistence, comments timeouts, avatar fetches, and takeover microphone ownership.
Known limitations
The physical ScreenCaptureKit motion-source stage could not run on the development machine (its Screen Recording grant sees wallpaper only), so that gate is unverified here; the rest of the recording-studio suite passed through native preview reattach. The account-auth live smoke was skipped for want of a one-time test token; those paths are covered by desktop and Rust tests.