Skip to content

Large Libraries

Run SnapByFace over tens of thousands of photos and hours of video: incremental re-indexing, FAISS vector search, pause/resume/cancel, and recovery after an unexpected quit.

SnapByFace is built for a whole archive, not a sample folder. This page explains what happens when the library is big, and how to keep every later run cheap.

Incremental processing

Before analyzing a file, SnapByFace checks whether anything actually changed. A file is skipped when all of the following still match what is stored in the index:

  1. File size — unchanged.
  2. Modification time — unchanged.
  3. SHA-256 digest — unchanged.
  4. Index version — the stored features were produced by the current app version.

If any one of them differs, the file is analyzed again; everything else is skipped. In practice:

  • A second run over an untouched library finishes in a fraction of the first run’s time.
  • Re-encoding or editing a file re-analyzes just that file.
  • Copying a folder to a new location re-analyzes it, because the stored state belongs to the original file record.

Embeddings are searched with FAISS. If FAISS is not available in your installation, SnapByFace falls back to a NumPy brute-force search.

:::note The NumPy fallback returns the same matches — not a lower quality of result, only a slower one, and the gap grows with library size. See Troubleshooting. :::

Controlling long runs

  • Pause — stop consuming CPU without losing progress.
  • Continue — resume where it paused.
  • Cancel — stop; files already finished stay indexed.
  • Close and reopen — on startup SnapByFace asks whether to continue an unfinished task, so an unexpected quit or a reboot does not throw away hours of work.

Practical advice

  1. Start with one folder. Index a representative folder first, check matches and threshold, then add the rest.
  2. Run big jobs overnight. A first pass over tens of thousands of images or hours of video is hours of CPU work.
  3. Keep media on a fast local disk. Network shares and spinning USB drives are usually the bottleneck, not the face model.
  4. Do not edit or move media mid-run. Changes queue those files for re-analysis anyway.
  5. Use a coarser video interval for the first pass — 2–5 seconds across a large archive, then tighten it on the folders that matter.
  6. Pause rather than force-quitting. Progress is checkpointed either way, but pausing is cleaner.

Storage and memory

  • The SQLite index lives at ~/.snapbyface/snapbyface.db. It grows with the number of detected faces and sampled video frames, not with the byte size of your media.
  • The face models ship with the app, so the index never stores them.
  • Memory use scales with the number of vectors held for search; very large libraries benefit from having FAISS active.

Re-indexing from scratch

If you need a clean rebuild — for example after changing the video sampling interval across the whole library — close SnapByFace, delete ~/.snapbyface/snapbyface.db, and let the next run rebuild it. Activation state lives in license.dat, so re-indexing does not deactivate your license.

:::caution Deleting the database removes all matches and all extracted face data. Your original photos and videos are never modified by SnapByFace — only its own index is removed. :::

How much time to expect

  • Images: thousands per hour on a modern laptop, faster on Apple Silicon.
  • Video: dominated by the sampling interval — 1 s sampling means ~3,600 detections per hour of footage.
  • Re-runs: only changed files, so minutes rather than hours.

Next steps