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 pullrequired. 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
yuv420pand usesscale2refso resolution drift can't silently break the comparison. Also caps on the shortest stream withshortest=1so 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→x265rename): the backend was writing the score + event against the pre-rename path, so the updatedscan_resultsrow 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-nvencFloating tags (:latest, :edge, :nvenc, :edge-nvenc) track the most recent release of each lineage.