Skip to content

v0.1.9.8 — Docker quick start fixed, FFmpeg 7.1, security updates

Choose a tag to compare

@kosm1x kosm1x released this 27 Jul 08:12

Docker images and a Windows installer for VLMP 0.1.9.8.

Docker

docker pull ghcr.io/kosm1x/vlmp:0.1.9.8

Multi-arch (linux/amd64 + linux/arm64), with SLSA provenance and an SBOM.

Windows

vlmp-setup-0.1.9.8-win-x64.exe is attached. SmartScreen warns on unsigned installers — "More info → Run anyway". Verify first:

Get-FileHash vlmp-setup-0.1.9.8-win-x64.exe -Algorithm SHA256
# c996f058bb2e166925ef32ce0f03f0100f6b0281951f261875dbd5a9a778d3b3

Since v0.1.9.4

This release rolls up everything from 0.1.9.5 through 0.1.9.8 — the previous four tags published container images only.

Fixes that change behaviour

  • The documented Docker quick start now works. docker compose up -d on a fresh clone used to crash-loop: data/ is gitignored, so the bind mount target did not exist, so the daemon created it root-owned — and the container runs unprivileged, so it could not write to it. Data now lives in a named volume (vlmp-data), which inherits the image's ownership. See the README for backup/restore and how to opt back into a host folder.
  • Startup failures now exit non-zero. A boot error used to be logged and then exit 0, which Docker and systemd both read as a clean, intentional stop. Supervisors now see a failure.
  • Transcode pacing actually applies. -readrate_initial_burst needs FFmpeg >= 6.1, but the runtime image shipped 5.1, so the pacing added in v0.1.4 was silently inactive in every published container. The image is now on Debian 13 (FFmpeg 7.1).
  • Session teardown no longer signals reaped processes. ChildProcess.killed records that a signal was sent, not that a process is alive, so teardown could signal a PID the kernel had already reassigned to something unrelated.

Security

  • fastify 5.10, @fastify/static 10, plus transitive fast-uri and brace-expansion updates. npm audit reports 0 vulnerabilities, down from 10 (1 critical, 8 high).

Versioning

  • The 4-part MAJOR.MINOR.PATCH.BUILD scheme is now used verbatim everywhere — the git tag, package.json, /api/info and the installer filename all read 0.1.9.8. Previous builds encoded this as npm pre-release syntax (0.1.9-4), which is why the older installer asset is named differently.