Verified via exiftool against real Sony ARW, Canon CR2, and Pixel DNG
files pulled from are-nas -- same EXIF DateTimeOriginal/CreateDate
tags as JPEG, no new codepath needed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Verified against real files pulled from are-nas: confirmed the tool
correctly leaves already-correct EXIF-dated photos untouched and only
flags the ones actually missing real metadata (validates the earlier
manual fix was precisely targeted). Recursive --dir walk now prunes
@eaDir/#recycle/#snapshot/.SynologyWorkingDirectory instead of wasting
time on generated thumbnails. Fixed a misleading "no files given"
error when --dir was given but --only-photo/--only-video filtered
everything out.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Generalizes the tool beyond QuickTime video containers, based on what
we found fixing a Synology Photos mass-wrong-date bug: the indexer
only reads photo-EXIF fields and never video container metadata, even
though most cameras embed a real timestamp there.
- .avi via exiftool's RIFF DateTimeOriginal (local time, no offset)
- .jpg/.jpeg/.png/.tif/.tiff/.heic/.heif via exiftool's EXIF DateTimeOriginal
- exiftool fallback for .mp4/.mov when ffprobe finds neither QuickTime tag
- placeholder "clock never set" timestamps (e.g. 0000:00:00 00:00:00)
are treated as no metadata, not a real date
- --dir for recursive directory batch mode
- interactive y/N confirmation by default; --yes for unattended runs
Verified against real files: a 2007 camcorder AVI, a synthetic UTC-tagged
MP4, and an EXIF-tagged JPEG all round-trip correctly, including DST
handling.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Extracted the mtime-stamping logic added to concat_live_clips.py into
its own dependency-free script (just needs ffprobe), so it can be run
against any video file -- not just Live Photo clips -- to fix a
mismatched filesystem mtime for tools like Synology Photos that sort
videos by mtime instead of parsing embedded metadata.
ergosteurandClaude Sonnet 5