I meant to write this up sooner, but every time I sat down another release dropped and the changelog grew longer.
So rather than publish four separate posts, I’m rolling everything up here: v2026.05.1, v2026.05.2, v2026.06.0, and v2026.06.1, all at once.
Four releases in under 30 days, and there’s a lot to unpack.
A quick note on versioning if you’re new here: Anthias releases follow a YYYY.0M.patch scheme. So v2026.05.1 means the second release of May 2026, v2026.06.0 is the first of June, and so on. It makes it easy to see at a glance how recent a build is and how far you are from the latest.
I’ve tried to lead with what matters most to everyday users and save the deeper technical material for the end.
Let’s get into it.
Video playback: we fixed it. For real this time
Video playback on Anthias has been a persistent source of frustration.
On Raspberry Pi 4, we were seeing thousands of dropped frames per minute during a 60-second clip (in some tests, close to 3,000). On Pi 5, frame rates were capping at around 8-10 fps even though the hardware was perfectly capable of more. On x86 PCs, video was outright broken under the compositor we use. On the older Pi 2 and Pi 3, VLC had been doing the heavy lifting for years in a way that was never quite right.
We fixed all of it.
On Pi 4 and Pi 5, we rewired the entire video rendering pipeline to run inside the same Qt process as the rest of the viewer, using Qt’s native multimedia stack. Previously, video was handed off to a separate process that then had to compete for control of the display hardware. That’s where those thousands of dropped frames were coming from.
With the new approach, there’s no competition, no handoff, no contention. Pi 4 dropped from ~3,000 frame drops per minute to zero. Pi 4 also had a separate rendering issue capping presentation at 8.3 fps regardless of how well the hardware decoder was performing. That’s fixed, and Pi 4 now runs at a steady 30 fps. Pi 5 went from 10-12 fps to 26.6 fps.
We ran 12-hour mixed-media burn-in tests across all supported hardware with zero crashes.
On Pi 2 and Pi 3, we replaced VLC entirely with a hardware-accelerated GStreamer pipeline that feeds directly through the Broadcom codec hardware. The result on Pi 3: 1080p30 playing cleanly with zero dropped frames. VLC is gone from the image.
On x86 PCs, video had been completely broken because playback conflicted with the Wayland compositor’s exclusive hold on the display. We now route playback correctly through Wayland and have bundled the right hardware decode drivers so Intel and AMD machines use their GPU for decode instead of doing it in software.
If you run Anthias primarily for video playback (which is most people), this release is worth upgrading for this alone.
Rotate your screen without touching a config file
This one’s been a long time coming. You can now rotate your display (0°, 90°, 180°, or 270°) directly from the Settings page in the Anthias UI.
Previously, getting portrait mode required editing config files manually, and which file to edit depended on your hardware. It was one of those things that felt approachable from the outside (“it’s just a rotation setting, right?”) and turned out to be genuinely fiddly in practice.
Now it’s a dropdown. It works on all supported hardware. The change takes effect on the next reload without restarting anything. That’s it.
Turn your screen on and off via HDMI-CEC
If your display supports HDMI-CEC (and most modern TVs and commercial displays do), Anthias can now turn it on and off directly through the HDMI cable.
There’s a new Display power section in Settings (marked “Experimental” for now) where you can toggle the display on and off without needing a smart power strip, an IR blaster, or any other add-on. For operators who want to schedule display on/off times, this removes the last reason to need extra hardware. It also works via the API if you want to script it: POST /api/v2/display/on and POST /api/v2/display/off.
The section only appears on hardware where CEC is actually available, so if you’re running on a regular PC, you won’t see it and nothing changes for you.
Paste a video URL and Anthias handles the rest
You can now paste an HTTP or HTTPS video URL directly into the asset manager and Anthias will download it into your local asset library in the background. It gets run through the same codec normalization flow as anything you’d upload manually.
For live streams (RTSP, HLS, and similar), Anthias detects them automatically and keeps them as streaming sources rather than trying to download them. They play live in the viewer as expected.
There’s a 5 GB cap on downloads, and failures show up as per-asset error messages so you know what happened. A small thing, but it eliminates a common friction point: finding a video online and having to download it to your laptop first before you can get it onto your displays.
Migrate from Anthias to Screenly with a wizard
We’ve replaced the old command-line migration tool with a proper multi-step wizard built into Settings. If you’re running Anthias and want to move to Screenly (or just sync assets over), you no longer need to open a terminal.
The wizard lets you validate your Screenly API token right in the UI, pick which assets to migrate with a checkbox list, see per-asset status as the upload happens, and retry any failures selectively. It doesn’t store your API token anywhere; it’s forwarded per request and forgotten.
Anthias now runs on a much wider range of ARM hardware
If you’ve been trying to run Anthias on something other than a Raspberry Pi (a Rock Pi, an Orange Pi, an Odroid, anything running Armbian on a 64-bit ARM chip), this release adds formal support for that hardware category.
We’ve tested end-to-end on a Rock Pi 4B and validated across several SoC families (RK3399, RK35xx, Allwinner H6, and Amlogic S905X3-generation chips). All asset types (images, H.264/H.265 1080p60 video, and web pages) work. Ubuntu-based Armbian isn’t supported yet, but Debian-based Armbian is good to go.
This has been a community request for a long time. If you’ve got a drawer full of SBCs that aren’t Raspberry Pis, give it a try.
1 GB boards stay stable now
Pi 2, Pi 3, Pi 4 1 GB, and similar boards with limited RAM were OOM-crashing after some of the video improvements introduced earlier this year. We’ve added graceful degradation for these boards: the memory-hungry preloading behaviour is automatically disabled when the system detects less than ~1.5 GB of RAM, saving around 100 MB of physical memory per device.
A couple of things to know: above-1080p video uploads are capped at 1080p on these boards (we downscale at upload time), and there’s a “Low-RAM mode” badge on the Diagnostics page so you can see at a glance how your device is configured.
If you’ve been having stability issues on older hardware, this should help.
A few fixes you’ll notice immediately
Screen rotation on Pi 4 is actually working now
There was a bug where 270° rotation was being treated as -90°, causing portrait displays to stretch instead of rotate. The eglfs backend on Pi 4 also wasn’t picking up the rotation setting at all. Both are resolved.
Deleting an asset via the UI now actually deletes the file
The API delete path was already handling this correctly, but the UI form-post had drifted and was only removing the database row, leaving the actual video or image file sitting on disk. On a device running 24/7 for months, this would quietly fill up your storage. Both paths now go through the same cleanup logic.
Deleting or deactivating a currently-playing asset takes effect immediately
Before this fix, if a one-hour image was on screen and you deleted it, it would keep playing for the rest of the hour. Now the viewer checks immediately and moves on.
The 4K splash screen is no longer cropped
On 4K displays, Plymouth was showing a 1080p splash centered on a black background. We now ship a proper 3840x2160 master.
For the technically curious
The viewer binary has been renamed from AnthiasWebview to AnthiasViewer, with the D-Bus service name updated to match. Two new internal API endpoints (GET /api/v2/viewer/playlist and GET /api/v2/viewer/settings) formalize the contract between the viewer and server. Both are gated by an internal token and don’t expose operator credentials.
All outbound HTTP from the server now carries an Anthias/<release> User-Agent string, which makes it easy to identify Anthias traffic in CDN logs and server-side analytics.
If you’re running Anthias behind a reverse proxy (Caddy, Nginx, Cloudflare Tunnel, or similar), two CSRF-related fixes are worth knowing about. First, requests from the same host that differ only in HTTP vs HTTPS scheme no longer trigger 403 errors. Second, you can now set CSRF_TRUSTED_ORIGINS=https://signage.example.com explicitly for proxies that rewrite the upstream Host header.
We also shipped a bin/balena_fleet_maintenance.py tool for anyone managing Balena fleets at scale. It rolls pinned devices forward to newer releases in controlled tranches, with a dry-run mode and progress tracking via Balena tags.
Three CodeQL security findings were resolved: a path injection issue in asset uploads (hostile filenames can no longer smuggle path traversal characters into the destination path), an open redirect in the login flow, and a stack trace that was leaking into 400 error responses.
The full technical changelog is in the release notes on GitHub for anyone who wants to dig deeper.
Upgrading
Existing installations upgrade automatically. If you’re on Balena, fleet management and legacy data migration are handled in-container, so your existing playlists survive the upgrade.
As always, the latest documentation lives at anthias.screenly.io.
Thank you to everyone who filed issues, tested builds, and contributed code over the past two months. The video playback overhaul in particular involved a lot of back-and-forth with the community to reproduce edge cases across different hardware. We genuinely couldn’t have done it as well without that feedback.
More to come.
Happy displaying.
