Recordings & retention

Fregata can record continuously, only when something happens (motion, an object detection, an “alert” event), or some mix of the two. The behavior is configured per-camera in config.yml and the data lands under ~/Fregata/media/ by default.

Two kinds of recording

• Continuous recording lives under recordings/ — segmented MP4s that cover the full timeline. Disk-hungry but invaluable when something happens between triggers.
• Event clips live under clips/ — short MP4s tied to a detection event (a person walked through the front-porch zone, a car pulled into the driveway). Cheap to keep for a long time.

The web UI’s Review tab is built on event clips; the Recordings tab plays continuous segments. Both work even when detection is paused.

Configuring per-camera

The minimum config to enable recording on a camera looks like:

cameras:
  front_porch:
    ffmpeg:
      inputs:
        - path: rtsp://user:[email protected]:554/h264Preview_01_main
          roles: [record, detect]
    record:
      enabled: true
      retain:
        days: 14
        mode: motion
      events:
        retain:
          default: 30
          mode: active_objects

What that does:

• Records continuously, but only keeps the last 14 days of segments where motion was detected (mode: motion — the rest are pruned every 24 hours).
• Keeps event clips for 30 days when an object was actively visible (mode: active_objects); shorter than the default 60 because event clips add up fast on a busy camera.

The full Frigate config keys for record: and snapshots: are documented upstream — see the Frigate docs on recording. The whole schema works on macOS unchanged.

Disk budgeting

A rough rule of thumb for an H.264 1080p main-stream camera at 15 fps and a sane bitrate:

Mode	≈ per camera per day	14-day retention
Continuous, all segments	25–40 GB	350–560 GB
mode: motion (typical street)	4–10 GB	60–140 GB
mode: motion (low-traffic)	1–3 GB	15–40 GB
Event clips only	0.1–0.5 GB	1–7 GB

HEVC (H.265) cuts roughly 30–40 % off these numbers if your camera encodes it. On Apple Silicon, encoding event clips with hevc_videotoolbox is essentially free — see Performance.

Tip

When you’re sizing a new install, the safest approach is start with mode: motion and short retention, watch the actual disk growth for a week, then dial up.

Where recordings land

~/Fregata/media/
├── recordings/<camera>/<YYYY-MM-DD>/<HH>/<MM.SS>.mp4
├── clips/<camera>-<event-id>.mp4
├── clips/thumbs/                  # event thumbnails (jpg)
├── clips/triggers/                # synthetic clips for trigger pipeline
└── exports/                       # user-initiated exports

The path layout is the same as upstream Frigate. If you’ve been running Frigate in Docker before, the Recordings tab and your file shape will be familiar.

Changing the media location

Two ways:

1. Tray menu — Settings → Folders → Change Media Location… Pick a new folder. Fregata will move the existing files on next launch and update the path env var. This is the friendlier route.
2. Set FRIGATE_MEDIA_DIR in Settings → Environment Variables. This bypasses the move logic — the new dir starts empty. Useful if you’ve separately copied or symlinked the data first.

The destination should be on a fast SSD with stable, low-latency writes. External USB drives work; spinning rust can keep up for one or two cameras but is a bad choice for many.

Pruning by hand

Fregata prunes on a 24-hour cycle. To reclaim space immediately:

# Drop everything older than 7 days right now.
find ~/Fregata/media/recordings -type f -mtime +7 -delete

# Then trigger Frigate's index cleanup the same way it would on
# its next prune cycle:
curl -X POST http://localhost:8971/api/recordings/cleanup

The first command frees the disk; the second updates the SQLite index so the web UI doesn’t show ghost segments.

TimeLapse / hyperlapse exports

The web UI’s Recordings tab has an Export button — pick a time range, optionally apply a speed multiplier, and Fregata renders an MP4 to ~/Fregata/media/exports/. Encoding is hardware-accelerated on the dedicated media engine, so a multi-hour timelapse usually finishes in less time than the source footage’s running time.