Resource Guards and Recovery

Resource Guards and Recovery

A replay recorder runs for hours, often all day. Small leaks in a driver or encoder that would never matter in a ten-minute recording can matter a lot over a long session. Flashback watches its capture worker for exactly that, and replaces it cleanly before a problem reaches your game. This page explains what's watched and what happens next.

The short version: only the capture worker is measured, against its own settled baseline, so opening the editor never looks like a leak. Real, sustained growth gets the worker replaced at a clean segment boundary; a hang stops only the worker. What you'll notice: usually nothing at all.

Watch the right process

Flashback measures only the capture worker process, never the whole app. Its private memory, handle count and thread count are compared with a settled baseline taken after the session has started and calmed down.

That matters because the desktop host does plenty of legitimate work that uses memory: opening the window, scrolling thumbnails, running the editor, preparing an export. None of that can be mistaken for a recorder leak, because none of it happens in the worker.

Two independent checks

Check	What it looks for	How it avoids false alarms
Absolute ceilings	The worker going far above where the session started, in memory, handles or threads	Fixed from the session-start baseline, and a reading has to persist across several samples before it counts
Sustained growth	The worker's footprint creeping up from one segment boundary to the next	Measured from fresh, settled samples taken before each rotation, so the brief overlap while the previous file finishes isn't mistaken for retained memory

The checks are separate on purpose: a sudden spike and a slow climb are different problems with different fixes.

What happens when a check trips

              normal  ------------------------------> keep recording
                |
   sustained growth found at a boundary
                |
                v
   finalize the active segment at that boundary
   replace the worker (no new encoder started in the old one)
   --> history intact, buffer continues
                |
   over a hard ceiling
                |
                v
   one bounded stop so encoded footage is finalized
   --> terminate only if that stop fails
   --> start a fresh worker

• Sustained growth leads to a graceful replacement. In 0.8.0 the decision is made with the settled sample from just before the rotation, so the worker is replaced at the boundary where the growth was found, rather than recording one more full segment first. The active segment is finalized and confirmed, then a fresh worker takes over. Your replay history is unbroken.
• 0.8.0 also replaces the worker early when growth at each of the last few boundaries is on course to hit the hard ceiling at the next one. Without that, the ceiling would be reached mid-segment, where containing the worker costs the segment in progress.
• A hard ceiling gets one bounded stop, so the footage the worker already encoded is finalized and kept. Only if that stop fails is the worker terminated.
• A missed heartbeat, missed deadline or protocol error ends only the worker. The host and every confirmed segment remain.

Saves aren't caught in the middle. A save pressed during any of this waits for the stop to finish, then completes from the finalized segment, or follows the recovered-save rules described in Replay buffer and segment rotation.

Recovery after a crash

• A native failure finalizes what it safely can, then the worker restarts with bounded backoff, so a persistent fault doesn't spin your CPU.
• Repeated failures at startup stop after a few tries rather than looping.
• After a successful start, interruptions keep recovering until you stop the buffer.
• Native callbacks stuck past their deadline are quarantined inside the disposable worker rather than torn down in an unknown state. See Isolated capture worker.

Not fooled by normal behavior

Several situations look like growth but aren't, and the guards are tuned for them:

• A monitor reconnecting. When recording resumes after a display returns, thread counts rise for a normal reason. Since 0.7.38 this no longer triggers a worker restart.
• A file finalizing. The previous segment's encoder and file briefly overlap with the new one. Growth is judged from samples taken before the rotation, not during the overlap.
• The interface. Opening the window or editor uses memory in the host, which isn't measured.

What you'll see

Usually nothing. A graceful replacement happens at a segment boundary and the buffer carries on. If a worker had to be stopped abruptly, there may be a short gap in the buffer, and a clip saved across that time ends at the gap and says so instead of silently jumping over it.

If recovery happens often on your PC, it's worth a report. The log records each worker's exit code and its last health reading against the session baseline, which is usually enough to tell a driver fault from a settings problem. See Diagnostics and logs and Getting help.

How it's tested

The release gate requires a real capture session of at least an hour through at least 20 real segment boundaries while a game supplies motion, and any worker replacement, recovery or quarantine during that run fails it. See Release qualification and testing.

---

Related pages: Isolated capture worker · Replay buffer and segment rotation · Troubleshooting recording