v2.2.2

WaveFlow Server 2.2.2

A fix release, for two problems reported together in #444. The first stopped the image at startup when the host provided its data folder, as Home Assistant does. The second stopped the desktop app's playback about a minute into a track. Nothing changes in the API or the database.

Fixed

• The image starts on a data folder it did not create. The image used to start directly as its account (uid 4533). When the host provided the data folder and that folder belonged to root or to another account, the server stopped at once with unable to open database file. This happens with Home Assistant's add-on folder, NAS shares owned by another account, and bind mounts made by root. A share that refuses chown altogether (NFS with root squashed, some SMB mounts) gets a warning and the server starts anyway; it still needs the account to be able to write there.

  The container now starts as root and gives the data folder to the account. Only then does it start the server, as that account, so never as root unless you ask for it with WAVEFLOW_UID=0. docker exec waveflow waveflow-server … runs as that account too, so a command such as library add leaves no file the server cannot replace. If you used a chown -R 4533:4533 workaround, you no longer need it for a data folder the container hands over; one it leaves alone (see below) still has to be writable by the account.

  • Another account: set WAVEFLOW_UID and WAVEFLOW_GID (both 4533 by default). 0 keeps root, which suits rootless Podman.
  • --user (or user: in a compose file) still runs the server as the account you give, and skips the hand-over.
  • What is left alone: anything mounted inside the data folder, a hard link, and the target of a symbolic link keep their owner. A data folder set to /, reached through a link or placed under a folder that is not root's alone is not handed over at all, and the log says why.

  The operations guide has the details.

• Server playback in the desktop app no longer stops after a minute. The server answered every byte-range request with at most 8 MiB. HTTP allows a shorter answer, but the desktop app took its end for the end of the file. A FLAC streamed from the server therefore stopped after about a minute, and a high-resolution file sooner. An open range such as bytes=N- now runs to the end of the file, and a bounded range to the end it asks for. This applies to the native stream and to the Subsonic API alike.

Install

docker run -d --name waveflow \
  -p 4533:4533 \
  -v waveflow-data:/data \
  -v /path/to/music:/music:ro \
  ghcr.io/instazdll/waveflow-server:2.2.2

The image runs on linux/amd64 and linux/arm64, and is the same, digest for digest, on Docker Hub as instazdll/waveflow-server:2.2.2. latest now follows this release. The standalone archives for Windows, macOS and Linux are attached below, with SHA256SUMS over all of them. The same files are linked from this release's notes on download.waveflow.app, which hold whether or not GitHub answers.

Upgrading from 2.2.1

Pull 2.2.2 and start it on the same data volume. With an archive, use the new folder in place of the old one, carrying over what you changed in laptop.env. The database schema has not changed, so there is nothing to migrate.

With the default account, the first start gives the files it hands over (not those listed above as left alone) to uid and gid 4533. On a volume 2.2.1 wrote, that changes their group only: 2.2.1 let Debian assign that group number when its image was built, typically 999. A file that belonged to another account, a host user's in a bind mount for instance, changes owner as well, and that account may no longer be able to write to it. 2.2.1 still opens the volume should you need to go back, since it runs as the same uid. The hand-over changes owners, never modes: a folder or file that only its group could use (mode 0070, say) stays out of reach of both versions until you give its owner access with chmod u+rwX.

With WAVEFLOW_UID and WAVEFLOW_GID set to another account, the files handed over belong to that account instead, and 2.2.1, which runs as 4533, may not be able to write to them. Give them back to uid 4533 before you go back.

The image no longer declares a USER. It starts as root and steps down before the server runs. An image scanner that checks for a non-root default user will now report it.

A server on 2.2.1 with the update check turned on announces this release on its own.

Full changelog: CHANGELOG.md · v2.2.1...v2.2.2

Download

The server for one computer, without Docker: extract the archive and start waveflow-server inside it. Each archive holds the server, its own FFmpeg and a README.txt to read first.

System	Archive
Windows (x86_64)	waveflow-server-2.2.2-windows-x86_64.zip
macOS (Apple silicon)	waveflow-server-2.2.2-macos-arm64.zip
macOS (Intel)	waveflow-server-2.2.2-macos-x86_64.zip
Linux (x86_64)	waveflow-server-2.2.2-linux-x86_64.tar.gz
Linux (arm64)	waveflow-server-2.2.2-linux-arm64.tar.gz

The Windows executables carry a self-signed certificate and the macOS ones an ad-hoc signature, which neither system trusts, so both warn on the first launch: README.txt says what to click past. SHA256SUMS holds the checksums of them all, and ffmpeg-8.1.3-sources.tar.gz the source of the FFmpeg they carry.

Container image

docker pull ghcr.io/instazdll/waveflow-server:2.2.2

The same image, digest for digest, is on Docker Hub:

docker pull instazdll/waveflow-server:2.2.2

Also published as latest in both, for linux/amd64 and linux/arm64 (a Raspberry Pi 4 or 5 on a 64-bit system).