Cue Backups & Recovery

Cues, notes and show events are stored with the recording, not in a separate database. That makes a recording self-contained: copy the file to another Mac and its cues travel with it.

This page covers where that data lives, what copies exist, and how to recover one.

Where cues are stored

Every save appends a new copy to the end of the MP4. Nothing already in the file is rewritten, so each save leaves the previous version in place and the recording carries its own history.

The data sits in a uuid box, the extension mechanism the MP4 format defines for exactly this. Players skip boxes they don't recognise, so the extra data has no effect on playback, editing or anything else that opens the file.

Two consequences worth knowing:

• The file grows slightly with each save — by the size of the cue data, typically tens of kilobytes, not the size of the recording.
• Re-encoding or re-muxing the file elsewhere discards it. If you run a recording through another tool and get a new file out, its cues won't come with it. Export the cues first, or keep the original.

Recordings that use a sidecar (<recording>_cues.json) still work. ShowRevue reads and writes both, and uses whichever copy was written most recently.

The copies ShowRevue keeps

Versions inside the recording

Because saves append, every version ever written is still in the file, oldest first. A bad save doesn't remove the good one before it.

Versioned backups

Before every save, a copy is written to two places:

~/Library/Application Support/ShowRevue/CueBackups/<recording>-<id>/
<folder containing the recording>/.showrevue-cue-backups/

Both are used on purpose. The Application Support copy survives the recording being moved, renamed, or living on a drive that's been unplugged. The copy beside the recording survives a wiped app container and travels with the footage when you hand it to someone else.

Files are named so you can read them without opening anything:

2026SHOW_DressRehearsal_1__20260819-143052__271cues.json

The most recent backups are kept, and always the one holding the most cues — so a run of short saves can't push the last complete copy out of the window.

The folder beside the recording is hidden

.showrevue-cue-backups starts with a dot, so Finder hides it. Press ⌘⇧. in Finder to show it.

Crash-recovery copy

While a session is open, ShowRevue keeps a hidden recovery file beside the recording:

.<recording>.revushow-cues-recovery.json

It is only removed once the cues have been written somewhere else and read back to confirm the write landed. If a save fails — a full disk, a disconnected drive — the recovery file stays, and it is the copy to reach for.

What stops a bad save

A recording only accepts its own session's metadata. Every recording carries the date and time it was made, and a save whose metadata belongs to a different session is refused rather than merged. This matters when an old recording is open in Playback while a live session is receiving cues from a desk: the live cues can't be written into the recording on screen.

Saves are verified. After writing, the data is read back and the cue count checked before the recovery copy is removed.

Fewer cues than the file already holds is recorded. That can be legitimate — you deleted some — so it isn't blocked, but the previous version is backed up first and the log says so.

Auto-heal on open

Most recovery happens on its own. When you open a recording, ShowRevue gathers the best copy from every store that keeps history — the copies appended inside the file, a _cues.json sidecar beside it, and the pre-save backups — and loads the fullest one whose recording date matches the file's own (within a second). The date match means a heal can only ever restore this recording's cues, never mix in another session's.

Comparing modification times isn't enough on its own: a degraded save still bumps the file's timestamp, so an older-but-complete sidecar would lose a plain date race. Picking the richest copy avoids that. It's loss-free, because lighting and media cues are never deleted — a smaller cue count always means degradation, so preferring the larger copy can't resurrect anything you removed on purpose. Deleting a note or cuepoint leaves the cue count unchanged, so those deletions stand.

Whatever is loaded is written back into the file on the next save. If the fullest copy came from a sidecar or backup rather than the file itself, a banner tells you how many cues were restored and where from, so a silent heal never goes unnoticed.

Recovering cues by hand

If a recording still opens with cues missing or wrong:

• Don't save over it. Nothing is lost yet, and a save is the one thing that can add to the confusion. Close the recording if you're unsure.
• Look in .showrevue-cue-backups beside the recording, or in ~/Library/Application Support/ShowRevue/CueBackups/.
• Pick the file with the highest cue count in its name — not necessarily the newest.
• Copy it next to the recording and rename it <recording>_cues.json.
• Open the recording. ShowRevue uses the most recently written copy, so the restored sidecar is picked up.

If there is no backup, check for the crash-recovery file described above, and for an earlier export — a CSV or PDF from Reports still holds the cue list, and cue numbers, labels and wall clock times can be rebuilt from it.

Getting cues out of a recording

Backups are insurance, not an archive. For anything you want to keep independently of the file:

• Reports exports the cue list as CSV, PDF or Final Draft.
• Cloud shows keep notes and cuepoints server-side as well; see Data & Security.

Housekeeping

Backups are small — JSON, a few tens of kilobytes each — and old ones are pruned automatically. There is nothing to maintain. If you're clearing space, the folders are safe to delete, with the obvious caveat that you're deleting the copies you'd want if a save went wrong.