2026.10.0 went out on 16 October. It is a stability release — every change in it is a fix, and most came from what devices in the field were actually reporting.
The last release announced here was 2026.08.1, so if that is where you are, upgrading will take you through 2026.08.2 and 2026.09.0 as well. All three are covered below.
What’s in 2026.10.0
Four of these were doing visible damage on real devices:
- Celery stopped killing its own workers. A soft time limit was armed against the job slot rather than the task body, so on a memory-pressured board a late signal would land on a worker that had already finished and gone idle — and it would exit 1. This single defect was the largest source of errors across the fleet. (#3391)
- SQLite is no longer corrupted by its own backups. Backups were taring the live WAL sidecar files, so a restore replayed one database’s log into another and produced
database disk image is malformed. Separately,journal_mode=WALwas re-asserted on every connection and leaked a file descriptor each time — one device went fromdatabase is lockedtounable to open database filein a single afternoon. (#3383) - The viewer waits for the database schema instead of crash-looping. On a slow first boot, or right after a restore re-created every table underneath it, it was querying tables that did not exist yet and restarting into the same race. (#3384)
- Assets stuck on “Processing” now fail with a reason. Five media tasks carried a hard time limit and no soft one, so an overrun killed the worker outright and left the asset row sitting at Processing with nothing to explain it. (#3385)
Playlists also drift less: the per-asset wait is now anchored to the start of each tick rather than added flat after it, so two players on the same playlist no longer separate by seconds over a few hours (#3328 — a first contribution from DiasonD, thank you).
Known limitation. The 512 MB Pi 3 A+ class of board is below the floor for this stack. Pre-release burn-in confirmed it cannot sustain a mixed playlist — it holds with a single image asset and wedges on a webpage or streaming asset. That is a long-standing memory ceiling on that hardware rather than anything introduced here; the board was already deep in swap at idle on the previous release. Pi 2, Pi 3 (64-bit), Pi 4, Pi 5, x86, Rock Pi 4 and NanoPi R3S all soaked clean.
Coming from 2026.08.1? One change needs your attention
As of 2026.09.0, /ws requires a logged-in session when authentication is enabled (#3324). Anything that connects to the websocket unauthenticated — a dashboard, a script, your own integration — will stop working until you give it credentials. If you have not enabled authentication on your devices, nothing changes for you.
The rest of 2026.09.0 is mostly uploads. Large assets transfer in chunks so they clear a proxy body limit, uploads and asset content stream instead of buffering into memory, you can drop a file anywhere on the schedule page, and a failed upload now tells you why it failed.
Also in 2026.09.0: upgrades purge superseded images (#3292). Before this, every release you upgraded through left a full copy of the stack — roughly 3 GB — on the card forever, and docker system prune would not touch it because the images were still tagged. If you have been upgrading for a while this is worth having; see SD card completely full for how to reclaim the space you have already lost, since the upgrade itself needs room to run.
2026.08.2 added two hardware warnings to the web interface: one when the power supply cannot hold its voltage, and one when the storage card starts developing bad blocks. Both tell you what to do about it rather than just reporting a fault.
Upgrading
Re-run the installer over your existing install:
bash <(curl -sL https://install-anthias.srly.io)
Full release notes: 2026.10.0 · 2026.09.0 · 2026.08.2
If something breaks, start a thread in Anthias and we will pick it up.