Screen-Pirate: Continuous Recording Feasibility

Question

Can screen-pirate run continuously (8+ hours/day, every day) without problems?

Short Answer

Yes, with the current settings (1 FPS, h264_videotoolbox). The main constraint is disk space, which is manageable with automatic cleanup.

Resource Analysis

Disk Usage (the real constraint)

From benchmarks (60-second runs, 1512x982 resolution, 1 FPS): - Video: ~2.5 MB/min (~40 KB/s average bitrate) - Input JSONL: ~10-20 KB/min (depends on activity) - Per hour: ~150 MB - Per 8-hour day: ~1.2 GB - Per week: ~6 GB - Per month: ~25 GB

These are typical-activity numbers. Static screens compress better (h264 P-frames are tiny when nothing changes). Heavy scrolling/video playback would push higher, but 1 FPS caps the damage.

With the default 30-day cleanup (pirate clean --older-than 30), steady state is ~25 GB. A 1TB drive handles this easily. Even a 256GB laptop drive has room.

CPU

All engines measured 0.1-0.2% CPU. The work is: - ffmpeg: hardware-accelerated via VideoToolbox (Apple Silicon encoder). Negligible CPU, runs on the media engine. - CGEventTap callback: fires on input events only. Mouse throttled to 30 Hz. Near-zero CPU. - No sustained CPU load. This won't affect battery life meaningfully.

Memory

All engines: ~5 MB RSS. This is dominated by: - ffmpeg child process (~3-4 MB) - CGEventTap runloop overhead (~1 MB) - The implementation language doesn't matter — C, Rust, ASM, and Python all land at 5 MB. - 5 MB is negligible on any modern system (0.03% of 16 GB).

File Handles

• 2 open files: input.jsonl (append) + session.json
• 1 ffmpeg subprocess with its own handles
• Well within OS limits (macOS default: 256 per process)

Potential Issues

1. Session File Size

The input.jsonl file grows linearly. At ~15 KB/min with moderate activity: - 8 hours: ~7 MB (fine) - 24 hours: ~21 MB (still fine, but consider rotating)

The video file is the bigger concern. ffmpeg writes a single .mp4 per session. A single 8-hour file would be ~1.2 GB. This works but: - If the process crashes, the MP4 may be corrupt (no moov atom written yet) - Seeking in a huge file is slow for later processing

Recommendation: Rotate sessions every 1-2 hours. Start a new session directory automatically. This limits data loss from crashes and keeps files manageable.

2. ffmpeg Long-Running Stability

ffmpeg with avfoundation capture is designed for long recordings (surveillance cameras use it). The VideoToolbox encoder is stateless per-frame. No known memory leaks in this configuration. The main risk is if the display configuration changes (resolution change, external monitor connect/disconnect) — ffmpeg may error out.

Recommendation: Monitor the ffmpeg process. If it dies, restart it in a new session.

3. macOS Sleep/Wake

When the Mac sleeps, ffmpeg and the event tap pause. On wake: - CGEventTap usually survives sleep/wake cycles - ffmpeg may produce a timestamp gap but continues recording

If either breaks, the daemon should detect and restart.

4. Disk Full

If the disk fills up, ffmpeg will error and the JSONL write will fail. The daemon should monitor available space and stop gracefully (or trigger cleanup) before hitting 0.

Recommendations for Always-On Recording

1. Session rotation: New session every 1-2 hours (cron or built into daemon)
2. Auto-cleanup: Run pirate clean --older-than 30 daily via cron or launchd
3. Health monitoring: Check ffmpeg is alive every 60s, restart if dead
4. Disk guard: Stop recording if disk drops below 5 GB free
5. Use the C engine: Smallest binary, lowest overhead, most predictable behavior
6. Install the LaunchAgent: pirate install — auto-starts at login, restarts on crash

Bottom Line

At 1 FPS with hardware encoding, continuous recording is essentially free in terms of CPU and memory. Disk is the only resource that accumulates, at ~1.2 GB/day. With session rotation and auto-cleanup, this can run indefinitely.