CRESA Begins Building for When Game Capture Fails

Making capture state visible

Following the previous work on learned capture profiles and validation, CRESA begins exposing more of that information to the broadcast itself. A dedicated capture status service and browser source are introduced, giving CRESA a way to communicate the current state of game capture instead of leaving capture behaviour hidden entirely in the background.

This creates the foundation for both the operator and presentation systems to understand whether capture is working, changing or experiencing a problem.

Planning for failure

Reliable automation cannot assume that everything will always work. Development therefore begins on a dedicated game recovery experience for situations where CRESA knows a game should be present but the expected capture state cannot be maintained. Rather than simply leaving the stream with a frozen, missing or broken game feed, the recovery system begins providing an intentional presentation state that CRESA can activate while the underlying problem is handled.

Recovery becomes state-driven

The first recovery browser scene is introduced and connected to CRESA's recovery state. Different demo states are also added so the behaviour can be exercised during development without requiring a genuine capture failure every time. This begins separating two important situations:

• A game is active and capture is healthy
• A game is expected, but capture requires recovery

That distinction gives CRESA considerably more context about what is actually happening during a broadcast.

Building for the imperfect stream

This work represents another change in how CRESA approaches automation. It is not enough for the suite to know what to do when everything is healthy. It also needs defined behaviour for when something goes wrong.

Instead of allowing a capture failure to become an unexplained broken screen, CRESA begins treating recovery as a first-class broadcast state.