Anthias 2026.05.1 | Screenly

Anthias 2026.05.1: Smoother video on Raspberry Pi 4, and uploads are checked against what your board can decode

Thu, 28 May 2026 00:00:00 +0000

If you show video on a Raspberry Pi 4, it plays more smoothly from Anthias 2026.05.1. On every board, check your video files: a video your board can't decode is now refused when you add it, including H.264 on a Raspberry Pi 5, and you convert it on your own computer with a command Anthias gives you.

From this release, video on a Raspberry Pi 4, a Raspberry Pi 5, x86 and generic arm64 boards plays inside the viewer itself, instead of in a separate mpv player that shared the screen with it. In the project's own testing, a 1080p60 H.264 video on a Raspberry Pi 4 went from dropping most of its frames to dropping none. The Raspberry Pi 2 and 3 keep using VLC.

On a Raspberry Pi 4 the viewer now runs at 1920x1080, also on a 4K display, so web pages and images show at 1080p there too.

Uploads are checked, not re-encoded

Anthias 2026.05.0 re-encoded a video on the device when its codec wasn't one the board played directly, which could keep a small board busy for a long time. Anthias 2026.05.1 never re-encodes anything. When you add a video, it reads the codec and accepts the file only if your board can decode it:

Board	Codecs accepted
Raspberry Pi 2 and 3	H.264
Raspberry Pi 4	H.264 and HEVC
Raspberry Pi 5	HEVC
x86	H.264 and HEVC

The Raspberry Pi 5 has no H.264 decoder Anthias can use, which is why it takes HEVC only. For 4K on a Raspberry Pi 4, the project's board notes recommend HEVC, since 4K H.264 is more than that board's decoder keeps up with. Other 64-bit ARM boards are covered in the generic arm64 entry.

A video that doesn't pass shows a "Failed" label in the content list. Click it and the "Processing failed" dialog says which codec was refused and which ones your board supports. It also shows an ffmpeg command with your file name filled in, and a "Copy command" button, so you can re-encode the file on your own computer and upload the result.

The check applies to uploads in the web interface and through the API, and to videos Anthias downloads, from YouTube or from a URL posted to the API.

If this affects you: on a Raspberry Pi 5, an H.264 video, which Anthias 2026.05.0 played as it was, is now refused. On every board, a video in a codec outside the table (VP9 or MPEG-4, for example), which 2026.05.0 re-encoded for you, is now refused, and so is HEVC on a Raspberry Pi 2 or 3. Re-encode those files to a codec in the table before you upload them. On a Raspberry Pi 5, Anthias 2026.07.0 accepts H.264 again.

Anthias 2026.05.1: Posting a video URL to the API now downloads the file

Thu, 28 May 2026 00:00:00 +0000

If a script or integration of yours adds videos to Anthias through the API by URL, those videos now download to the player and play from there, so the player needs disk space for each one. Videos added in the web interface aren't affected.

When you create an asset through the API with mimetype set to video and an http:// or https:// URL that points at a single video file, Anthias now downloads the file to the device and plays it from there. The asset shows as "Processing" until the download and the codec check finish. Before, Anthias stored the URL and played it from the origin server every time, so playback depended on that server being reachable.

This applies to API v1.2 and v2. v1 and v1.1 keep storing the URL as it is.

What counts as a downloadable video

URLs that end in .mp4, .webm, .mov, .mkv, .avi, .m4v or .ogv.
URLs with no file extension, when the server answers a HEAD request with a video/* content type. If the server doesn't answer that way, the URL is kept as a stream, as before.

Live streams stay as they were and play from the origin: rtsp://, rtmp://, srt://, udp:// and mms:// URLs, and HLS, DASH and Smooth Streaming manifests (.m3u8, .mpd, .m3u, .ism).

A download is capped at 5 GiB and 15 minutes. If it fails, because the server returns an error, the response isn't a video, or the file is too large, the asset shows "Failed" with the reason.

The "From URL" tab in the web interface is unchanged and still stores the URL without downloading it.

If this affects you: if you post video URLs to API v1.2 or v2, the device now needs enough free disk space for each file, and a video in a codec your board can't decode is refused. If you want a URL to keep playing from its origin, use a streaming URL or API v1 or v1.1.

Anthias 2026.05.1: Experimental HDMI-CEC controls turn the display on and off

Thu, 28 May 2026 00:00:00 +0000

If the screen is a TV, you can now switch it on or off from Anthias's Settings page. The controls are experimental, and on a Raspberry Pi 2, 3 or 4 they only work from Anthias 2026.08.1, which fixes them.

Settings has a new "Display power" section, marked Experimental, with "Turn display on" and "Turn display off" buttons. They send the command to the connected display over HDMI-CEC, and a message tells you whether the command was sent. The section only appears when the device has a CEC adapter: /dev/cec0 on a Raspberry Pi 5, x86 or arm64 board, or /dev/vchiq on the older Raspberry Pi models. On a Raspberry Pi 2, 3 or 4 the controls couldn't work in this release: System info showed "CEC error" and the buttons failed.

Whether the TV obeys is up to the TV. A command the display doesn't answer within 10 seconds comes back as an error.

Raspberry Pi 5

On a Raspberry Pi 5 the CEC device wasn't passed into the Anthias containers, so the "Display Power (CEC)" card on the System info page read "CEC error". Upgrading to Anthias 2026.05.1 passes /dev/cec0 and /dev/cec1 through, and that's also what makes the new buttons appear there. On x86 and arm64 boards the upgrade passes /dev/cec0 through when the board has one.

For developers

POST /api/v2/display/on and POST /api/v2/display/off do the same thing. They return 200 when the command was sent, 502 when the display or adapter refused it or didn't respond, and 503 when the device has no CEC adapter.

Anthias 2026.05.1: Anthias copies your content to Screenly from Settings

Thu, 28 May 2026 00:00:00 +0000

If you're moving from Anthias to Screenly, the cloud-managed product from the same team, you no longer need a script to bring your content along. Settings now has a "Migrate to Screenly" section, and its "Start migration" button takes you through the move:

Sign up or sign in to Screenly, from the link on the page.
Create an API token in Screenly (the page tells you where: Settings > Security > API Tokens), and paste it in. Anthias checks the token before going further, and doesn't store it on the device.
Choose which content to copy. Everything starts selected.
Start the migration and watch the progress bar. Each file that fails shows its own error without stopping the rest, and a retry button runs the failed ones again.

Files that live on the player, such as images and videos, are uploaded from the device to Screenly. Content that is a URL, such as a web page or a stream, is sent as a link. Everything lands in a group called "Migrated from Anthias". Nothing already in your Screenly account changes. Anthias doesn't check for copies, though, so running the migration twice uploads the content twice.

The page uses Screenly API v4.1 and replaces the tools/migrate_assets_to_screenly.py script, which is removed in this release.

Anthias 2026.05.1: Anthias installs on Armbian and other 64-bit ARM boards, as best effort

Thu, 28 May 2026 00:00:00 +0000

If you have a Rock Pi, Orange Pi or Banana Pi in a drawer, you can now run Anthias on it, as best effort. Images and web pages work on any of these boards, and video works on the Rock Pi 4.

Before, install.sh stopped with "Unsupported Raspberry Pi model" on anything that wasn't a Raspberry Pi or an x86 PC. From Anthias 2026.05.1 it treats any other 64-bit ARM (aarch64) board as a generic arm64 device, skips the Raspberry Pi boot changes (config.txt, cmdline.txt), and installs the same web interface, scheduler and viewer. The boards named in the project's README as tested are the Rock Pi 4, Rock 5, Orange Pi 5 and Banana Pi M5.

What to know before you try it

Use the Debian-based Armbian image for your board (Bookworm or Trixie). The installer sets up Docker from Docker's Debian repository, so an Ubuntu-based Armbian image fails at the first apt update.
On a generic arm64 board, Anthias refuses video uploads, because it can't tell which codecs the board handles. Images and web pages work.
The Rock Pi 4 is the 1 board Anthias recognizes by name. It accepts H.264 and HEVC uploads there, and decodes them in software. In the project's testing, 1080p H.264 dropped about 1 frame every 14 seconds, while 1080p HEVC dropped about a fifth of its frames.
Audio goes to the system's default ALSA device. If your HDMI output needs something else, set it in ~/.asoundrc.
The Anthias boot splash usually doesn't show on these boards, so the kernel's boot messages stay on screen until the viewer starts.
Wired network interfaces named end0, common on Armbian, are recognized, so the splash screen shows the board's IP address.

Anthias 2026.05.1: A Screen rotation setting turns x86 displays to portrait

Thu, 28 May 2026 00:00:00 +0000

People have asked for a portrait setting since 2021. Settings now has a "Screen rotation" dropdown with 4 choices:

Landscape (0°)
Portrait (90°)
Landscape, inverted (180°)
Portrait, inverted (270°)

On an x86 player, pick one and save, and the whole display turns: web pages, images and video. There's no reboot and nothing to set in the compositor.

On Raspberry Pi boards, Anthias 2026.05.1 doesn't fully apply the setting yet. On a Raspberry Pi 2, 3 or 4, video turns but web pages and images stay upright, and on a Raspberry Pi 5 or a generic arm64 board nothing turns. Keep rotating those displays the way you do today. The Pi 4 turns everything from Anthias 2026.06.1, the Pi 5 and generic arm64 boards from 2026.07.0, and the Pi 2 and Pi 3 from 2026.07.3.

For developers

/api/v2/device_settings has a new screen_rotation field, with the values 0, 90, 180 and 270.

Anthias 2026.05.1: Boards with 1 GB of RAM run in a low-memory mode

Thu, 28 May 2026 00:00:00 +0000

A board with 1 GB of RAM has little room for the viewer, a web page and a large video at the same time. From Anthias 2026.05.1, a board with less than 1.5 GiB runs in a low-memory mode. That covers every Raspberry Pi 2 and 3, and the 1 GB versions of the Raspberry Pi 4 and the Rock Pi 4. The mode makes 2 changes:

The viewer doesn't load the next web page ahead of time. Each page loads when its turn comes, so you see a brief black screen between web pages.
A video with more pixels than 1920x1080 is refused at upload, even when its codec is fine. The "Failed" message explains the limit, and the ffmpeg command it shows scales the file down to fit.

The Memory card on the System info page shows a "Low-RAM mode" note when the mode is on. Boards with 2 GB or more are unaffected.

For developers

The memory object in /api/v2/info has a new low_ram field, true when the mode is on.

Anthias 2026.05.1: Players boot quietly, and the installer now overwrites config.txt

Thu, 28 May 2026 00:00:00 +0000

From Anthias 2026.05.1, a Raspberry Pi boots to the Anthias splash without a rainbow screen, scrolling text or a login prompt first, and an x86 player skips the scrolling text too. If you've added your own lines to config.txt on a Raspberry Pi, such as an overlay for a HAT or a forced display mode, copy them somewhere before you run the installer to upgrade, because it now rewrites that file.

A player in a lobby shouldn't show a rainbow screen, scrolling kernel messages or a login prompt before the content starts. The installer sets a Raspberry Pi up for a quiet boot: the firmware's rainbow splash is off, the kernel prints nothing to the screen, and there's no login prompt on the first console. On x86, the installer adds the quiet and splash options to GRUB, so the Anthias splash shows instead of kernel text.

config.txt and cmdline.txt

On a Raspberry Pi, the installer now writes config.txt and cmdline.txt in the boot partition (/boot/firmware on Raspberry Pi OS Bookworm and Trixie) from a template, every time it runs. Before, it changed individual lines in config.txt and left the rest alone.

Lines you added to config.txt are replaced. A custom dtoverlay, hdmi_group or overscan line won't survive the next run.
The template sets disable_overscan=1, display_auto_detect=1 and dtparam=audio=on. On a Raspberry Pi 5 it also sets dtoverlay=vc4-kms-v3d,cma-512, which 4K HEVC playback needs.
cmdline.txt is built from the cmdline.txt.orig copy the installer saved on its first run. Only the root= entry and any cfg80211. options (the Wi-Fi country setting from raspi-config) are kept from it. Other options in that file are dropped.

If this affects you: if you've added your own lines to config.txt or cmdline.txt.orig, such as an overlay for a HAT or a forced display mode, copy them somewhere before you run install.sh to upgrade. Once it runs, they're gone, and adding them back by hand only lasts until the next time it runs.

Anthias 2026.05.1: Forms in the web interface work behind an HTTPS proxy

Thu, 28 May 2026 00:00:00 +0000

If you reach Anthias through something that adds HTTPS in front of it, such as a Caddy sidecar, a Cloudflare Tunnel or Tailscale Serve, sign-in, uploads and saving settings could fail with a 403 page saying "Your session expired", and uploads with "Upload failed". From Anthias 2026.05.1 those requests go through without any change on your side, as long as the browser and Anthias agree on the host name. The same goes for a browser that keeps using HTTPS after you turned SSL off.

When the proxy changes the host name

Some proxies, such as IIS ARR, send Anthias a different host name than the one in your browser, and then the request is still refused. The simplest fix is to have the proxy pass the original Host header through: proxy_set_header Host $host; in nginx, ProxyPreserveHost On in Apache, or preserveHostHeader="true" in IIS ARR. Caddy and Traefik do this by default.

If you can't change the proxy, Anthias also reads a CSRF_TRUSTED_ORIGINS environment variable in the anthias-server container. Set it to the address people use, for example https://signage.example.com, and separate several addresses with commas. It is empty by default.

Anthias 2026.05.1: Free disk space in the info API now reads 15.0 GB instead of 15G

Thu, 28 May 2026 00:00:00 +0000

If a script or monitoring tool of yours reads free disk space from the Anthias API, it needs a small change, because the figure now reads like 15.0 GB instead of 15G. Otherwise, you'll only notice the new form on the System info page.

free_space in the response of /api/v1/info and /api/v2/info used to be a short string such as 15G. From Anthias 2026.05.1 it is a number with 1 decimal, a non-breaking space and a full unit, such as 15.0 GB. The units are KB, MB, GB and TB. The disk figures on the System info page are written the same way.

If this affects you: anything that parses free_space from the info API, such as a monitoring script, needs to accept the new form, including the non-breaking space between the number and the unit.

Anthias 2026.05.1: Removed content leaves the screen right away, and other fixes

Thu, 28 May 2026 00:00:00 +0000

Fixes

Deleting or turning off content that is on screen takes effect right away. Before, an image set to show for an hour stayed up until the hour ended, which people had reported since 2025.
Deleting content in the web interface also deletes its file from ~/anthias_assets. Before, the content disappeared from the list and the file kept using disk space.
With audio set to HDMI on a Raspberry Pi 4 or 5, sound plays through the HDMI port that has a display connected, and the first port when both do. Before, it always used the first port.
Videos uploaded through API v1 and v1.1 now go through the same codec check as other uploads. Before, such a video never became playable and could sit on "Processing" indefinitely.
Content that has shown "Processing" for more than an hour, for example after a restart in the middle of a job, is retried automatically.
Asking the API for content that doesn't exist returns a 404 instead of a 500 error.
On fresh installs of Anthias 2026.05.0, the host agent service failed to start, so the device's IP address wasn't detected and /api/v2/info took more than a minute to answer. Installing or upgrading to 2026.05.1 fixes it.
Upgrading an install that dates from before the Anthias rename no longer fails on a leftover srly-ose-redis container holding port 6379.
On x86, scheduled background tasks, such as clearing out leftover upload files, no longer stop at random.
The Anthias icon shows in Raspberry Pi Imager.

Improvements

Web pages in the viewer are requested in the device's language, so sites with several languages show the right one. Anthias reads the language from /etc/default/locale (which raspi-config and update-locale write) when you install or upgrade, so a change applies after the next upgrade. On balena, set a LANG device variable.
install.sh shows a menu of the 10 most recent releases, with "latest" (the tip of master, which is now the testing channel) and "other" for typing a tag. Its prompts use whiptail instead of gum, and it stops with a clear message if you run it as root, with sh instead of bash, or without network access.
The boot splash fills a 4K display. Before, it showed as a 1080p picture in the middle of a black screen.
Video downloads from a URL and the Screenly migration identify themselves with a User-Agent of Anthias/<release> (+https://anthias.screenly.io).
The splash screen no longer falls back to an IP address saved at install time, which could be out of date once the network changed. It shows "Detecting network…" until it has the current address.
Security fixes in the web interface and the API, and Django 5.2.14 and Pillow 12.2.0, which include security fixes of their own. Upgrading is recommended.

Upgrade notes

The viewer's browser stores its data in a new place, and the old data isn't copied. After upgrading, web pages start with an empty browser profile, so a page that relied on a sign-in saved in the viewer needs signing in again.

For contributors

Pushes to master now publish container images only, as the testing channel. Balena deploys and disk images are built when a GitHub release is published, with balena-cli 25, and rpi-imager.json is attached to each release.
The WebView is built as a stage of the viewer image, instead of in a release workflow of its own.
The viewer binary is now AnthiasViewer and its D-Bus service is anthias.viewer. The Qt source moved from webview/ to src/anthias_webview/. The viewer reads the active playlist and its settings from /api/v2/viewer/playlist and /api/v2/viewer/settings, which only accept a token the viewer holds.
Video on Raspberry Pi 4, Raspberry Pi 5, x86 and arm64 no longer goes through an mpv process. Playback uses QtMultimedia inside the viewer, with the Raspberry Pi libav packages pinned in docker/_rpt1-ffmpeg-pin.j2.
docs/board-enablement.md describes a repeatable playback test, and bin/generate_board_enablement_testbed.sh builds the 8-clip set it uses (H.264 and HEVC, 1080p and 4K, 30 and 60 fps).
bin/test_webview_cpp.sh runs the viewer's C++ tests.
The installer adds docker-buildx-plugin on every board, so building the images on the device works.
A marketing-screenshots workflow, run by hand, captures screenshots from the Playwright integration suite for a slider on the Anthias website. FAQ entries on the website have links you can share, and the README points to the website for supported hardware.
New tests cover remote video downloads, the Screenly migration, the CSRF origin check, board detection and the viewer's video player.

Dependencies updated.