v0.3.2

VMAF-focused release. Fixes three real-world VMAF bugs observed in
production (bimodal scores on sibling episodes, score/event lost on
rename, no in-app way to verify the score per file) and closes a
UX gap in the update-notification system so new releases surface on
running containers without a manual image pull.

Changed

• File-detail History tab now always shows the VMAF score when the file has one in scan_results, synthesising an entry if the original VMAF file-event is missing (older conversions pre-dating the logging feature, or events logged against a pre-rename path). Makes it easy to spot-check individual files surfaced by the VMAF filters without opening the job's full encoding log.
• Update-available notification now surfaces on the running container within ~30 minutes of a new GitHub release, no manual docker compose pull required. Previously the server-side cache window was 6 hours AND there was no background refresher, so the "Update available" pill could take most of a day to appear — or never, if the container happened to check just before the release. Matches how Sonarr / Radarr / Plex advertise updates. The Settings → Updates "Check for updates" button now also bypasses the cache so a manual click always reflects live GitHub state.

Fixed

• VMAF analysis: reported suspiciously low scores (e.g. 43 on visibly near-transparent encodes; back-to-back same-show episodes at 57.7 and 97.7) due to pixel-format or resolution mismatch between the reference and encoded streams inside the libvmaf filter graph. The filter now explicitly normalises both sides to 8-bit yuv420p and uses scale2ref so resolution drift can't silently break the comparison. Also caps on the shortest stream with shortest=1 so a trailing-frame discrepancy no longer inflates error. Logs now include min / max / harmonic-mean alongside the mean score, and emit a "distribution looks bimodal" warning when a sub-80 mean coexists with a ≥90 max — a signature of measurement artefacts rather than genuine quality loss.
• VMAF score / event no longer lost on files whose name changes during conversion (e.g. x264 → x265 rename): the backend was writing the score + event against the pre-rename path, so the updated scan_results row and the file-history query — both keyed on the post-rename path — never saw them. Both writes now use the post-rename path.

Docker images

Pinned to this release:

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

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