Anthias 2026.09.0 | Screenly

Anthias 2026.09.0: Large uploads work behind a proxy, and a failed upload says why

Tue, 22 Sep 2026 00:00:00 +0000

Put Anthias behind a reverse proxy or a tunnel and large videos used to fail to upload, even though everything else worked. Anthias puts no limit on how big an upload can be, but the proxy usually does: Cloudflare's Free and Pro plans, for example, cap a request at 100 MB, which a few minutes of video clears easily. From Anthias 2026.09.0, Add asset > Upload file sends a file larger than 16 MiB in 16 MiB pieces, one after another, and the device puts them back together. Each piece clears the proxy on its own. Smaller files upload in one request, as before.

A piece that fails on a dropped connection or a server error is sent again, up to 2 more times, so one hiccup doesn't throw away an upload you've been waiting on. A file Anthias won't accept, such as an unsupported type, is refused on the first piece rather than after the whole file has gone up. An upload you abandon halfway is cleaned up once it has sat for an hour without a new piece.

Changing the piece size

If your proxy's limit is lower than 16 MiB, ask for smaller pieces. Add upload_chunk_size_mb under [main] in ~/.anthias/anthias.conf, which survives upgrades, and restart Anthias. On balena, set the ANTHIAS_UPLOAD_CHUNK_SIZE_MB device variable in the dashboard instead. If both are set, anthias.conf wins.

The value is in MiB (1 MiB is 1,048,576 bytes), from 1 to 24. A value outside that range is moved to the nearest limit, a decimal is rounded down, so 8.5 becomes 8, and anything that isn't a number is ignored in favor of the default of 16. Each request carries a little more than the piece itself, so leave some room under your proxy's limit.

A failed upload says why

Before, almost every upload failure showed the same generic message, asking you to check the file and try again. Now the message points at the cause:

A file the server or a proxy refuses as too large says it exceeds the upload size limit of the server or a proxy in front of it, so you know to look at the proxy rather than the file.
If a proxy refuses even a single piece, the message tells you to lower the upload chunk size.
A connection that drops mid-transfer says so, and suggests a smaller file too, because some browsers report a proxy's size refusal as a dropped connection.
If the last piece went up and no reply came back, the message says the upload may have finished and to check the asset list before uploading again, since a second attempt would make a duplicate.
A page that has gone stale asks you to reload it and try again.
A server error points you to the device logs.

For developers

Uploads through the API, POST /api/v1/file_asset and POST /api/v2/file_asset, are written to disk as they arrive instead of being read into memory first. The content endpoints in API v1 and v2 (assets/<id>/content) stream their response too, where they used to hold several copies of the file in memory. In the project's testing on a Raspberry Pi 3 B+, fetching a 150 MB asset through the content endpoint ran the server out of memory, and the API stayed down for about 40 seconds while it restarted. After the change, the same request added about 12 MB to the server's memory.

The content endpoints return the same JSON as before, with the file as base64 in content. For file assets the response is now always application/json, so the browsable API page no longer renders them.

Anthias 2026.09.0: Files dropped anywhere on Schedule Overview upload

Tue, 22 Sep 2026 00:00:00 +0000

From Anthias 2026.09.0, you can drag images and videos from your desktop and drop them anywhere on Schedule Overview, including the asset list, the navigation bar and the margins, and they upload. Until now only the upload area inside Add asset took a drop. A file dropped anywhere else made the browser open the file itself and leave the page.

While you drag, the page shows "Drop to upload". When you let go, Add asset opens on Upload file and shows the progress there, "File 2 of 5" for example, then closes when the last file is in. If a batch is already uploading, the page says "Upload already in progress" instead, and you can drop the new files once it finishes. While another dialog is open, such as Edit asset or a preview, a drop doesn't upload, and a message asks you to close the dialog first.

Anthias 2026.09.0: Live updates in the web interface need a signed-in session

Tue, 22 Sep 2026 00:00:00 +0000

If you only use the web interface in a browser, nothing changes for you. This only matters if you turned on authentication and run a script or dashboard of your own that listens for the web interface's live updates: from Anthias 2026.09.0, it has to sign in first.

The web interface keeps the asset list current through a WebSocket connection at /ws. When authentication is turned on, Anthias 2026.09.0 accepts that connection only from a browser with a signed-in session, the same rule every page of the web interface already follows. A browser you use the web interface in is already signed in, so nothing changes there. If you run Anthias without authentication, which is the default, /ws stays open as before.

Turning authentication on or off, or changing the username or password, closes the open connections. The web interface reconnects by itself and has to pass the new settings to get back in.

If you run Anthias with authentication on, upgrade to get this.

If this affects you: with authentication on, a script, dashboard or other client that opens /ws without signing in is refused from 2026.09.0, with a 403 at the handshake. Username and password sent as HTTP Basic credentials aren't accepted on /ws either, even though the API still takes them. Sign in through the web interface's login page and send the session cookie you get with the handshake.

Anthias 2026.09.0: Backups carry only what Anthias needs, and restores check the version

Tue, 22 Sep 2026 00:00:00 +0000

A backup you download from the Settings page now holds your settings and content and leaves out half-finished uploads, and a restore stops before changing anything if the backup's database is newer than the player can read. If you turned on HTTPS, keep your own copy of its certificate, because backups no longer include it.

From Anthias 2026.09.0, "Get backup" and "Upload & recover", under Backup & restore on the Settings page, work only with what Anthias runs on: the settings file anthias.conf, the database, the backups folder of database dumps, the default assets list and your content. Before, a backup took everything in ~/.anthias and ~/anthias_assets. Other files that sit in ~/.anthias, such as the certificate and key that bin/enable_ssl.sh installs in ~/.anthias/ssl, are no longer put in a backup, and a restore won't write them back. If you rely on those, keep your own copy.

Half-finished uploads and downloads in the content folder are left out too. They can be gigabytes of something nobody finished sending, and they only made the archive bigger.

Restores check the version

Each backup now records the Anthias release and the version of the database it came from. A backup whose database is newer than the restoring Anthias understands is refused before anything is written, with a message to upgrade Anthias to at least the release that made it. A backup from an older version restores, and its database is brought up to date right after. Backups made before 2026.09.0 carry no version, so they count as older and still restore.

Anthias 2026.09.0: Upgrades remove the old Anthias images they replace

Tue, 22 Sep 2026 00:00:00 +0000

Every upgrade pulls a fresh image for each Anthias service, and until now it left the previous ones on the card. The installer's cleanup only removed untagged layers, so the old tagged images stayed, and a device that had upgraded a handful of times carried several full copies of Anthias. One person who asked for a fix found the last 6 releases taking about 16 GB on their devices. Removing them took the cards from 76% full to 26%.

From Anthias 2026.09.0, the installer and bin/upgrade_containers.sh remove the old images as their last step, once the new containers are running. If the pull or the start fails, the old images stay in place to fall back on.

Only Anthias images are removed (ghcr.io/screenly/anthias-*, plus the older screenly/anthias-* and screenly/srly-ose-* names), and only those no container uses, running or stopped. Tagged images for other containers you run on the same machine are left alone. Untagged leftovers, which nothing can use, are pruned as the installer already did. Each removal is printed as "Reclaimed superseded image" followed by the image name, and a device with nothing to clean prints nothing.

To clear the leftovers from earlier releases without waiting for the next upgrade, run ~/anthias/bin/purge_stale_images.sh. It's safe to run at any time.

Anthias 2026.09.0: Boards recover on their own when memory runs out or the system hangs

Tue, 22 Sep 2026 00:00:00 +0000

On a board short of memory, the screen could freeze, or the whole board could stop responding until someone power cycled it. Anthias 2026.09.0 changes how both cases end.

Running out of memory

When memory runs out, the viewer container is meant to be what the system stops, because Docker then restarts it clean. Before, only the small script that starts the viewer was marked to go first, and stopping it freed almost nothing. In the project's testing on a 2 GB board with an RK3566 chip, the system stopped that script twice in a row, got back less than 200 KB each time, and still had to stop something else. Every process in the viewer container is now marked, so the first thing stopped is the viewer itself, and in the same test that freed about 100 MB at once.

A board that stops responding

When you install or upgrade with the installer, it now sets up systemd's watchdog with a 30 second timeout, so a board whose system hangs reboots by itself. Which watchdog it uses depends on the board:

Raspberry Pi boards use the Pi's hardware watchdog. Raspberry Pi OS already had it switched on with a 1 minute timeout, and Armbian and Debian ship it off.
On x86, any hardware watchdog the machine exposes is used, and the kernel's software watchdog otherwise.
Other boards, such as the Rock Pi 4 and the NanoPi R3S, use the software watchdog. In the project's testing, the hardware watchdog on both of those boards halted the board instead of restarting it, and it stayed dark until someone power cycled it. The software watchdog restarted the Rock Pi 4 within about 30 seconds.

A board with no watchdog that can restart it gets the watchdog switched off explicitly, rather than left to the system default. A reboot that hangs while shutting down is forced through after 5 minutes.

Anthias 2026.09.0: Less black screen when a video gives way to an image, and other fixes

Tue, 22 Sep 2026 00:00:00 +0000

Fixes

Add asset opens with an empty form every time. The URL of the last web asset you added no longer sits in the box, one press of Enter away from a duplicate, and the Apps tab starts from the list of apps instead of the last app's form.
The Actions column in the asset table fits its buttons, so the icons no longer spill past the edge of the table.
Going from a video or a web page to an image shows less black screen. While the image loads, the screen holds the last image Anthias showed instead of going black.
On Docker Compose installs of boards other than the Raspberry Pi, System info shows the board's name, such as FriendlyElec NanoPi R3S LTS, instead of "Generic aarch64 Device". The device_model field of /api/v2/info, which was empty on these boards, now has the name too.
When Anthias can't identify the board and so can't check a video's codec, the upload message says what to check: on Docker Compose installs, that anthias-host-agent and Redis are running. It used to tell you to re-flash with a board-specific image that doesn't exist.
Installing on Raspberry Pi OS Trixie no longer fills the output with Ansible deprecation warnings.

For contributors

The Ansible playbook reads gathered facts through ansible_facts, and the new ansible/ansible.cfg sets inject_facts_as_vars = False, so a bare fact reference fails instead of slipping back in. That file takes precedence over /etc/ansible/ansible.cfg when the installer runs the playbook.
New tests cover chunked uploads and their error messages, page-wide drag and drop, and the Add asset reset. A fake docker command tests the image cleanup, and an Ansible test runs the watchdog selection against made-up sysfs trees, which is how the x86 case is covered.
The repository has an MJML newsletter template in emails/, with a CI job that validates it and checks the compiled size against Gmail's clipping limit.
The Anthias website adds pages on free digital signage software and on Yodeck and piSignage, expands the Raspberry Pi pages, and links to the Screenly shop for buying a player.

Django moves from 5.2.14 to 5.2.17, which brings its upstream security fixes, along with the usual Python, JavaScript and GitHub Actions dependency updates.