Fixed
- Per-job progress bars stuck for ~60s at a time, then jumping in big increments — even after the v0.3.35 WebSocket fix. Inverting the ETA formula on stuck jobs showed both jobs' last DB-persisted progress was always ~57 seconds old simultaneously, while ffmpeg was happily burning ~380% CPU on each. Diagnosis: every ffmpeg progress line triggered an
aiosqlite.connect → UPDATE → commit → closecycle for that job's row injobs. Under contention from any other transaction holding the WAL write lock (some 60-second periodic loop in the codebase), all four progress writers (2 jobs × 2 lines/sec) queued behind it, blocked the converter's progress callback, and back-pressured ffmpeg's stderr buffer until the lock released and the queued events flushed in a burst. Fix: decouple DB persistence from live-UI updates. WebSocket broadcast keeps firing on every progress line (already throttled to 500ms per job server-side); the DB write is now throttled to once every 3 seconds per job, with a guaranteed flush on terminal progress (≥99.99) so the persisted final value is never off. Same throttle applied to the remote-workerreport_progressHTTP path (2-second interval) so busy nodes don't flood the server. Smoke-tested: 25 WS broadcasts vs 5 DB writes over 12 seconds, terminal flush guaranteed.
Docker images
Pinned to this release:
docker pull ghcr.io/i-ial9000/shrinkerr:0.3.36 # portable (amd64 + arm64, CPU)
docker pull ghcr.io/i-ial9000/shrinkerr:0.3.36-nvenc # x86_64 + NVIDIA GPU (NVENC)
docker pull ghcr.io/i-ial9000/shrinkerr:0.3.36-edge # as above but ffmpeg master
docker pull ghcr.io/i-ial9000/shrinkerr:0.3.36-edge-nvencFloating tags (:latest, :edge, :nvenc, :edge-nvenc) track the most recent release of each lineage.