prune

Syncs the database with what is actually on disk. It never deletes real files: only database rows, and cached data derived from photos that are already gone.

videre prune --dry-run                 # show what would be removed
videre prune                           # remove stale entries and refresh metadata
videre prune --silent                  # no per-file output
videre prune --db ~/photos.db          # use a specific database
videre prune --prune-unreachable       # also drop entries whose folder is gone
videre prune --force                   # allow an unusually large cleanup

When to run it

The usual moment is right after deleting duplicates:

videre dedupe | xargs trash    # files are gone from disk...
videre prune                   # ...now the database agrees

Until you do, videre stats still counts the deleted files, and reports still list them (they are filtered out at generation time, but the rows remain).

Also worth running after moving or reorganising folders by hand, since rows are keyed by path: a moved file looks like a deletion plus a new file, and the old row lingers until pruned.

Always look first on a library you care about:

videre prune --dry-run

What one pass does

1. Removes rows for files no longer on disk
2. Refreshes the stored timestamp of any file whose modification time has changed since the last pass
3. Deletes embeddings whose photo is gone, across every model
4. Deletes cached thumbnails whose photo is gone

Steps 3 and 4 are the reason to prune at all rather than ignoring stale rows: they are what actually reclaims disk space.

Step 2 only touches rows that actually differ, so the count tells you something. Its usual cause is videre fix-dates, which rewrites modification times from EXIF and deliberately leaves the database alone; running prune afterwards reports exactly the number of files it changed. On a library nothing has touched, the count is zero and a second pass is a no-op.