v0.3.137

Fixed

• Newly-converted Shrinkerr files (Coroner, Conviction, Conversations with Friends, Cook at all Costs, …) showing as NEW with converted=0 despite successful conversion jobs. Root cause: the worker's late post-conversion scan_results UPDATE was destroying the early site's correct work. Both sites use a v0.3.130 DELETE+UPDATE pattern; the early site (status='running') correctly renames h264 row → h265 with converted=1. The late site (status='completed', after update_status) then DELETEs the just-renamed row at h265, then UPDATEs WHERE file_path=h264 (matches 0 rows because already renamed). Net: scan_results loses the row entirely, the next watcher poll re-INSERTs it with is_new=1, converted=0, new_detected_at=now. v0.3.130 introduced this regression when it added watcher-race protection to both sites; pre-v0.3.130 the late site was just a no-op rename. Fix: late site now checks if a row at current_file_path already has converted=1 and skips the destructive DELETE+UPDATE if so. Plus a one-shot heal that retroactively fixes all rows wiped by this bug.

Docker images

Pinned to this release:

docker pull ghcr.io/i-ial9000/shrinkerr:0.3.137         # portable (amd64 + arm64, CPU)
docker pull ghcr.io/i-ial9000/shrinkerr:0.3.137-nvenc   # x86_64 + NVIDIA GPU (NVENC)
docker pull ghcr.io/i-ial9000/shrinkerr:0.3.137-edge    # as above but ffmpeg master
docker pull ghcr.io/i-ial9000/shrinkerr:0.3.137-edge-nvenc

Floating tags (:latest, :edge, :nvenc, :edge-nvenc) track the most recent release of each lineage.