How a recording survives a crash

On the third of September, at 12:29 in the afternoon, a test script did exactly what it was supposed to do. It killed a running instance of Cilevi mid-take, on purpose, to see what would happen to the recording underneath it. What happened is that a real four minute walkthrough at 4K came back as 118 MB of video with nothing able to open it. Not corrupted. Not missing a few seconds off the end. A file that ffprobe still answers with "moov atom not found" to this day, because it predates the fix below and there was nothing left to repair it with.

That file taught us more than any planned test would have, so here is what it taught us, and what a recording actually needs to survive a process dying underneath it.

Where the video is, and where the map to it is

An MP4 file is really two things stacked together: the video samples themselves, and a separate index that says how long the whole thing runs and where each piece sits inside the file. That index has a name, moov, and by default it goes down last, after the very last frame, because writing it any earlier would mean guessing a length nobody knows yet. Every player, and the operating system's own decoder, reads that index first before it will open the file at all.

Stop the process before the index is written and you are left with a file that is entirely real video and entirely unreadable, because nothing in it says where anything is. This is not really a bug. It is a default that nobody notices, because most recordings end when somebody presses stop, not when the process underneath them is killed.

Writing the map as you go, instead of at the end

The fix is to stop writing one big index at the end and write many small ones as you go. The file becomes a stream of short chunks, a few seconds each, and every chunk carries its own tiny index for just its own samples. A player can then walk the file chunk by chunk from the front, so it never needs the recording to have finished cleanly in the first place. Kill the recorder now and the same file opens and plays immediately.

That is the entire win, and it is a real one. It is also not the whole story, because two things a normal recording gets for free turned out not to come with it.

What "it opens" does not include

The length. A killed file reports a duration of zero, because the actual number of seconds is written into a single field that only gets filled in when a recording ends normally. Left alone, a twenty minute take would land on the timeline as a clip a few seconds long, or however long the editor happened to guess, which is worse than not opening at all because it looks like an answer. We rebuild the real length by walking every chunk and adding up how long its samples actually run.

The seek table. A cleanly finished file also carries an index of where every chunk sits, which is what lets you drag the scrub bar to the middle of a long recording and land there directly instead of decoding from the start. A killed file has none of that either. We proved it mattered by taking an ordinary, properly finished recording and deliberately cutting that one part back out: dragging the playhead anywhere past the first few seconds threw it back near the beginning, exactly like a crashed file. Which is also proof this never touched a single recording that closed the normal way.

What it costs to carry the map

Two 29 second recordings of the same desktop, measured here on 2026-09-04, put a real number on this. An ordinary file spends 11,543 bytes on its one closing index: 0.027 percent of the file. A file built to survive a crash spends 42,386 bytes across all its small indexes and the seek table: 0.100 percent. Both are small, but the honest way to say it is that the crash-safe version costs about four times as many bytes as the one that cannot be recovered.

The more real cost is time, not bytes. Whatever was being written the instant the process died does not come back, because it was still in flight and never landed anywhere whole. On one recording we tested this against on 2026-09-04, the source genuinely runs to 24.40 seconds and the recovered file plays cleanly to 23.37. We tried adding a closing marker at the true end anyway, and all it buys is a frame that freezes rather than a frame that plays, so we hand back what is actually watchable instead of a number that looks better on paper. If your machine dies a second before you meant to stop, that second is the one you lose. Every second before it, you keep.

Checked in an ordinary player, not just ours

We did not take our own decoder's word for any of this. A killed file, opened in an ordinary video player before Cilevi ever touched it, plays but will not let you drag the seek bar past the first few seconds. Open the same file once in Cilevi, close it, and open it again in that same ordinary player: it behaves like any other video now, because the fix rewrites the file itself rather than working around it while it is open. Wherever a recording ends up later, another editor, a phone, a colleague's laptop, the repair goes with the file, not with us.

The more common way to lose one, and it has nothing to do with crashing

A separate save runs quietly in the background about once a minute while you edit, and most of the time that is more than enough. But we found the gap in it the hard way. Recorded a take, opened it straight into the editor, closed the whole thing twelve seconds later. Nothing had been saved yet by the once-a-minute clock, so the next launch had nothing to offer back: a session existed, from a process that no longer did, with no autosave under it.

A recording you just made and have not touched yet is not really a document with unsaved changes in the usual sense. It is the only copy of something that happened once. So the first save now happens the moment the editor opens, before the one minute timer starts at all: measured on 2026-09-03 at 0.8 seconds after the window appears. Everything after that is what the minute-by-minute save is for.

What it looks like while you are working

A thin strip under the timeline says, in plain words, what just happened: Auto saved 12:31, or Auto saving, or nothing changed since the last one, so you are never guessing whether the last few minutes of edits exist anywhere but the screen in front of you. Every save, including the one that runs automatically right before an export starts, writes to a temporary copy first and only swaps it in once the write has actually finished, so a save interrupted halfway leaves the previous good copy standing instead of a broken one in its place. Recordings and every one of these autosave copies stay in a folder on your own machine and nowhere else, the same as everything the privacy policy already promises about what you record.

And if the editor itself does not close cleanly, for any reason, the next time it opens it checks for exactly that: a saved session with nobody left running to claim it. It asks, plainly, whether you want it back. None of this is a setting to turn on. We needed it before you did.

Four numbers, on purpose

The size, the two durations, the 0.8 seconds: we are giving you all four because a recovery feature you cannot see the edges of is one you can only trust blindly. This one has edges. We found most of them by losing our own recording first, and they are smaller now than they used to be.

If a recording of yours has ever come back broken, on this tool or another one, tell us what happened. And if you have not read why we built Cilevi yet, that is the post this one continues from.