Manatee

QuickTime says the screen recording failed to save

· 6 min read

You finish a long screen recording, click stop, and the save fails. Or the app quits before you get that far. Either way there is no file where you expected one, and the recording represented real work.

In most cases the data is still on the disk. macOS writes a screen recording to a temporary location while it is being captured and moves it into place when you save, so an interruption leaves the partial file behind rather than discarding it.

Where the partial file lives

Screen recordings in progress are written into a per-user temporary directory. Find it and look inside:

echo $TMPDIR
ls -lt "$TMPDIR" | head -20

Recordings often appear under a folder named for the capturing process, so search a little wider for anything recent and large:

find /private/var/folders -name "*.mov" -size +10M -mmin -240 2>/dev/null

That looks for MOV files over 10 MB modified in the last four hours. It will print some paths you do not care about; the one you want is the large recent one, usually with a name like Screen Recording followed by a timestamp, or a random string.

Also check the two places a completed recording normally lands, in case it saved somewhere unexpected:

ls -lt ~/Desktop | head
ls -lt ~/Movies | head

Copy anything promising somewhere safe before doing anything else:

cp "/private/var/folders/.../recording.mov" ~/Desktop/recovered.mov

Copy rather than move, and do it before you restart anything. Temporary directories are cleaned on reboot, and a restart at this point loses the file for good.

Testing whether the file is usable

A recovered partial file frequently will not play, and that is expected rather than fatal.

ffprobe -v error -show_entries format=duration,size \
  -show_entries stream=codec_type,codec_name \
  -of default=noprint_wrappers=1 ~/Desktop/recovered.mov

If it reports a real duration, the file is complete enough to use and you are finished. If it reports no duration, or errors, the index is missing, which is the normal outcome for an interrupted recording.

The reason is structural. In a MOV or MP4, the picture data lives in an mdat block and the index that maps playback time to positions lives in a moov block. The index cannot be written until the recording stops, so it goes last. A healthy file looks like this:

ftyp → free → mdat (the video data) → moov (the index)

Interrupt the recording and you keep every frame and lose the map to them. The file is large and unplayable simultaneously, which is why people assume it is empty when it is not. All of the recording is there apart from the last fraction of a second.

Repairing it

Rebuilding a missing index means reading through the frame data, working out where each frame starts, and writing a new index describing what was found.

Manatee does this for MOV and MP4 files, working from a duplicate so the recovered file you found is not altered by the attempt, which matters when it is the only copy. It reports how much it recovered rather than declaring success on a file that still will not open. For a screen recording interrupted at the end, the usual result is the entire recording minus the final moment.

A repair needs a reference for the stream layout, which for screen recordings is straightforward because they are consistent: same codec, same resolution, same frame rate throughout. Recordings that changed resolution partway, which happens if a display was connected or disconnected mid-capture, are harder and may recover only up to the change.

How to repair a corrupted MOV file covers the general case, and video file is 0 bytes or shows the wrong length covers the related symptom where a file exists but reports nonsense.

Why the save failed

Worth establishing, so it does not happen on the next recording.

The disk filled up. By far the most common cause for long recordings. Check the real figure rather than the Finder’s optimistic one:

df -h /

The Finder counts purgeable space as available and most applications cannot use it, which is why a recording can fail for lack of room while the Finder reports plenty. When your Mac says the disk is full and Finder disagrees explains the gap and how to reclaim space.

The destination was unavailable. Recording straight to an external drive or a network share, which then disconnected or slept, fails at the save. Record to the internal drive and move the file afterwards.

The Mac slept. A long recording with no interaction can let the machine idle-sleep. Prevent it for the duration:

caffeinate -d -i

Leave that running in a Terminal window while you record, and press Control-C when finished.

The app crashed. Long recordings at high resolution are demanding. Recording a region rather than a full Retina display reduces both the memory pressure and the file size considerably.

Reducing the risk next time

  • Check df -h / before starting anything long. Budget generously; a full-motion 1080p recording can consume gigabytes per hour, and high-bitrate capture considerably more.
  • Record to the internal drive.
  • Record a region rather than an entire Retina display.
  • Break long sessions into segments. Three twenty-minute files risk twenty minutes; one hour-long file risks an hour.
  • Run caffeinate -d -i alongside anything lengthy.

Questions

I restarted the Mac. Is the file gone? Almost certainly. Temporary directories are cleared on restart. Check ~/Desktop and ~/Movies in case it saved after all, but do not expect to find it in the temporary folder.

The file is there but it is 0 bytes. Nothing was ever written to it, so there is nothing to recover. This usually means the recording failed at the very start rather than at the end.

Can I recover audio if the video will not repair? Often yes. Audio and video are stored in separate streams, and a repair that cannot reconstruct the picture can sometimes still extract the sound. Worth trying when the recording was a meeting or narration.

Does the screenshot toolbar recording behave differently from QuickTime? The underlying capture is the same, and both write to a temporary location before saving. The search steps above apply to either.