Fixed
- Per-folder rescan ("Rescan" button on a title folder, e.g. to pick up a newly added sidecar subtitle) could leave the folder permanently empty in the listing if the underlying scan walk failed silently (uncaught ffprobe exception, permission hiccup, etc.). The pre-v0.3.97 sequence was delete-then-rewrite — the upfront
DELETE FROM scan_results WHERE file_path LIKE 'path/%'committed first, and exceptions insidescan_directorywere caught and logged but not propagated. Net result: rows wiped, none rewritten, "done" event fires, frontend re-fetches and finds zero rows under that path → folder vanishes from the listing. Maps exactly to user-reported "no files after rescan, then folder disappeared a few seconds later". - Fix flips the ordering to upsert-then-orphan-cleanup: rows are written via the existing
ON CONFLICT(file_path) DO UPDATEupsert as the walk progresses, and stale rows (files no longer present on disk under that path) are removed at the end — but only for paths whose walk completed without raising. If the walk errors mid-way, that path is excluded from orphan cleanup and existing rows survive intact. Failure mode is now graceful: the worst case after a broken rescan is a stale row, not a vanished folder. - Same logic applies to full-library scans, which had the same theoretical vulnerability — a partial scan failure used to leave the DB partially wiped; now it leaves it untouched.
Docker images
Pinned to this release:
docker pull ghcr.io/i-ial9000/shrinkerr:0.3.97 # portable (amd64 + arm64, CPU)
docker pull ghcr.io/i-ial9000/shrinkerr:0.3.97-nvenc # x86_64 + NVIDIA GPU (NVENC)
docker pull ghcr.io/i-ial9000/shrinkerr:0.3.97-edge # as above but ffmpeg master
docker pull ghcr.io/i-ial9000/shrinkerr:0.3.97-edge-nvencFloating tags (:latest, :edge, :nvenc, :edge-nvenc) track the most recent release of each lineage.