Consider an optional in-place metadata mode (re-upload model causes duplicate-checksum errors, ID churn & sidecar precedence)

[flowcool]

First, thanks for this tool — embedding Immich's DB metadata back into files is genuinely valuable for portability. I used it to geotag/date a ~19k-photo library and wanted to share some friction with the re-upload approach, in case an alternative mode is on your radar.

What I hit

Running -all -faces over a library where I'd just edited a lot of GPS/dates via the API:

1. duplicate key value violates unique constraint "UQ_assets_owner_checksum" — when the tool re-generates a file identical to one already embedded and re-uploads it, Immich rejects the insert. It surfaced as a large batch of Postgres errors (insert into "asset" ... returning *). Related upstream: Upload error: duplicate key value violates unique constraint "UQ_assets_owner_checksum" immich-app/immich#15051 and discussion #23206.
2. New asset IDs on every re-upload — the replacement gets a new UUID and the original is trashed. Any external references to the old ID drift, and the state cache (keyed by ID) no longer recognizes already-processed assets after such churn, causing re-processing loops.
3. XMP sidecars take precedence — the <file>.jpg.xmp sidecar is read by Immich before the embedded EXIF. If the DB metadata was wrong at embed time and later corrected, the stale sidecar silently re-pollutes the DB on the next metadata refresh. Cleanup then requires deleting the sidecar, not just fixing the JPG.

Suggestion / question

Would an optional in-place mode be feasible — exiftool -overwrite_original on the existing original, keeping the same asset ID, then refreshing Immich's stored checksum? It would avoid the duplicate collisions, ID churn, storage doubling during the trash window, and sidecar precedence issue.

I realize the tension: Immich has no clean "update checksum for this asset" API, so in-place would risk checksum divergence unless done carefully (I worked around it with a direct DB checksum update). So this may be more of a discussion than a quick fix — but flagging it since none of the above is currently documented, and the re-upload safety guarantees come at a real churn cost for large libraries.

Happy to share the exact repro / my workaround if useful. Thanks again!