v0.7.0
v0.7.0
Highlights
New repair-assets mode: takeout-json — clean up Google Takeout JSON sidecars
A known Google Photos Takeout export/import failure stores a photo's *.json metadata sidecar in place of the real picture. The asset is pure JSON with no image data — the header and pixels needed to reconstruct the photo are physically gone, so it is unrecoverable by any tool (verified: ffmpeg reports "No JPEG data found", and the upstream repair-takeout-photos carving tool repairs 0 of them). The only safe action is to remove the junk asset.
# Preview first (nothing is deleted)
immich-admin cw repair-assets --mode takeout-json --check-all-assets --dry-run
# Then remove them (to trash; add --force for permanent deletion)
immich-admin cw repair-assets --mode takeout-json --check-all-assets --yesDetection is deliberately the strictest in the tool. A file is only ever deleted when its leading bytes parse as a complete JSON object and carry the full Google fingerprint — title + photoTakenTime.timestamp + creationTime.timestamp + googlePhotosOrigin must all be present. A real image never parses as a JSON object at all, so a real photo can never be mistaken for a sidecar. Anything that doesn't match is reported skipped-not-sidecar and left completely untouched.
Verified against 26 real corrupt assets: 25/25 sidecars detected, and the 1 genuine video correctly left untouched.
Consistent with the other destructive commands: --dry-run, --yes, --force (permanent vs. trash), --ids-file, --check-all-assets and --album-id all apply. The mode is opt-in only and is not part of --mode all. --keep-original is rejected (there is nothing to keep).
Repair modes now point you at takeout-json
When marker, tiff-tags or all encounter an asset that is actually a Takeout sidecar rather than a repairable image, they now print a per-asset hint to rerun that asset with --mode takeout-json, instead of just reporting it as unrepairable. Supported image types reuse the bytes already downloaded for repair; other extensions (e.g. a .dng that is really a sidecar) are recognized by streaming only the file's head — no full download.
Removed the thumbhash-wait verification (behavior change)
The replace/repair flow no longer waits for Immich to generate a thumbnail before removing the original. Server-side thumbnail generation is asynchronous and its timing depends on too many factors (queue depth, server load, job scheduling) to bound reliably with a fixed timeout, which risked rolling back genuinely successful repairs. The original is now removed as soon as the repaired upload is checksum-verified and its metadata copied; a failed earlier step still leaves the original untouched and rolls back the new upload. Run find-no-thumbhash afterwards to confirm processing, or use --keep-original.
Full behavior
See the README for the complete client-workflow repair-assets documentation, detection details, and sample use cases.