Anthias release notes | Screenly

Anthias 2026.10.0: The background worker stops killing its own processes

Fri, 16 Oct 2026 00:00:00 +0000

On a board short of memory, Anthias kept stopping and restarting parts of itself, which cost the board time and memory it didn't have. It was the largest single problem in the crash reports Anthias devices send the project. Anthias 2026.10.0 stops it, and upgrading is all you need to do.

Anthias runs uploads, downloads, video probing and housekeeping in a background worker, the anthias-celery container. That worker kept killing its own idle processes and starting replacements. Its log filled with lines like these:

Process 'ForkPoolWorker-3' pid:412 exited with 'exitcode 1'
Timed out waiting for UP message from <ForkProcess(ForkPoolWorker-4, started daemon)>

The trigger was the soft time limit, the warning a task gets before its hard limit cuts it off. On a busy board that warning could arrive after the task had already finished, and the idle process that received it exited. From Anthias 2026.10.0, a warning that arrives when no task is running, or that was meant for an earlier task, is ignored. A task that really runs past its soft limit is still stopped, and one that hangs is still cut off by its hard limit.

The tasks that read the display's power state over HDMI-CEC and send telemetry could also catch the warning meant for them, carry on, and get killed by the hard limit. They now stop when they're told to.

Anthias 2026.10.0: Restoring a backup no longer corrupts or locks up the database

Fri, 16 Oct 2026 00:00:00 +0000

Restoring a backup from the Settings page could leave Anthias with a database it couldn't read, or one so locked that the web interface answered with server errors. A player upgraded from an older install could hit the second one too. Anthias 2026.10.0 fixes both, and backups made by earlier versions still restore.

Both problems were in the one SQLite database where Anthias keeps its assets and settings, ~/.anthias/anthias.db, which the web server, the background worker and the viewer all use at once.

Backups and restores

"Get backup", under Backup & restore in Settings, used to put the database in the archive together with its write-ahead log files, anthias.db-wal and anthias.db-shm, each read at a different moment while Anthias kept writing. "Upload & recover" then unpacked the archive over the live files. When the archive carried no log of its own, the old database's log stayed next to the restored database, SQLite replayed it into the wrong file, and the first read after the restore failed with database disk image is malformed.

Now a backup carries a single copy of the database, taken through SQLite at one moment, with everything in the log included and no log files beside it. A restore deletes the log files of each database it replaces before anything opens it.

Backups made before 2026.10.0 still restore. Their log files are skipped, which avoids the corruption but leaves out any changes that were still only in the log when the backup was made.

If the database can't be copied while its log holds changes that aren't in the main file yet, the backup now fails, and the "Get backup" download ends in an error, instead of producing an archive without those changes.

A database that hasn't switched to write-ahead logging

Anthias runs the database with write-ahead logging, so reads and writes don't block each other. It used to ask SQLite to switch to that mode every time it opened a connection. On a database that wasn't switched yet, such as one from an older install or one just restored, the switch needs the file to itself, and with 3 services using it the request failed with database is locked. Each failure left a file open, and the web interface answered with server errors. In the project's crash reports, one device went from database is locked to Too many open files to unable to open database file in a single afternoon.

Now each service checks the mode once when it starts, and switches it if it can. If the database is busy, Anthias carries on in the old mode, which is slower when several services write at once but works, and tries again at the next start.

Anthias 2026.10.0: Media that takes too long to process no longer stays on Processing

Fri, 16 Oct 2026 00:00:00 +0000

While Anthias prepares an upload or downloads a video, the asset shows "Processing" in the asset table. If that fails, the row shows "Failed", and clicking it opens the asset with the reason. Anthias 2026.10.0 fixes the cases where a slow job never got that far.

Jobs that run too long

Five of these jobs had only a hard time limit: reading a video's duration, preparing an image, preparing a video, downloading from YouTube and downloading a video from a URL. One that ran over was killed on the spot with no chance to update the asset, so the asset stayed on "Processing" with nothing to say why.

From Anthias 2026.10.0, each of them gets a warning 30 seconds before its hard limit and stops cleanly. An image or video that runs out of time while being prepared or downloaded shows "Failed" with a message such as "Timed out: processing did not finish within 270s". A video whose duration can't be read in time leaves "Processing" without a message. The limits themselves are the same as before: 2 minutes to read a video's duration or prepare a video, 5 minutes to prepare an image, and 15 minutes for a download.

Images over the size limit

Anthias refuses images over 50 megapixels. An image between 50 and 100 megapixels already said so, in a message written for developers. One over 100 megapixels, such as a large scan or a poster export, failed with the image library's own warning about a possible "decompression bomb DOS attack", which sounds far worse than an image that's too big. Now both say how big the image is, that the limit is 50,000,000 pixels, and to resize it and upload again.

Expected failures stop looking like crashes

A YouTube link that YouTube refuses (a 403 or 404, an age restriction, a region block), an image over the limit, and a source file that's gone by the time processing starts, for example because you deleted the asset while it was processing, are expected outcomes. The worker log now records them as a single line instead of an error with a traceback, and they're no longer sent as crash reports. If you point crash reporting at your own Sentry project with SENTRY_DSN, they stop showing up there too. The asset table shows the same as before: a YouTube refusal still shows "Failed" with YouTube's reason, and a deleted asset is gone.

Anthias 2026.10.0: The viewer starts more reliably after restores, slow boots and display restarts

Fri, 16 Oct 2026 00:00:00 +0000

The viewer is the container that puts content on the screen. Anthias 2026.10.0 fixes 4 ways it could get stuck starting up.

On a slow first boot, or right after a restore, the viewer could ask for the asset table before the database had its tables. It failed with no such table: assets and the container restarted into the same race. The viewer now waits until the database is fully set up, and logs Database is not migrated yet; delaying viewer startup every 30 seconds while it waits.
If an earlier display process was still holding the anthias.viewer name on the session bus, every new attempt to start one failed within half a second, and the viewer spent all 30 of its attempts on the same failure. In the project's testing on a Pi 5 that was close to 7 minutes of black screen. The viewer now finds the old process, asks it to exit, forces it if it won't, and starts the new one.
On the boards that run the Wayland compositor (Pi 5, x86 and arm64), the viewer used to treat a leftover socket from a compositor that had died as a running one, and gave up before the compositor came back. It now connects to the socket and waits until the compositor answers.
Changing "Screen rotation" or "Prefer dark mode" in Settings restarts the display process. The viewer now waits for the old one to exit before loading the next asset, instead of sending the asset to a process that was on its way out and stalling until it dropped off.

Clearer errors when the display process won't start

When the display process dies before it finishes starting, the viewer's error now says how it ended, such as killed by SIGSEGV (-11). Before, it ended on whatever the process last printed.
On the Pi 5, x86 and arm64 images, a display process that can't register on the session bus exits with status 1 and says which registration failed. It used to crash with SIGSEGV on the way out, which looked like a crash in the display process.
A display process that crashes now prints a stack trace on every board, which the viewer's error includes when the crash happens during startup. Before, only the 64-bit Pi 3 image printed one.

Anthias 2026.10.0: Players showing the same playlist drift apart less

Fri, 16 Oct 2026 00:00:00 +0000

Two screens in a shop cycling the same menu board in German and English used to drift apart, until after a few hours they switched languages seconds apart. The player started an asset's countdown only after it had refreshed the schedule, read the database and told the display to load the asset, so each rotation took the asset's duration plus that overhead, and the overhead differs from one device to the next.

From Anthias 2026.10.0, the countdown starts when the rotation does, so an image or web page with a 30 second duration rotates 30 seconds after its rotation began. If loading takes longer than a short asset's duration, the player moves straight on to the next one. The viewer log shows the wait next to the duration, for example Sleeping for 29.8 of 30s.

A video's duration is its length, so the overhead now comes off the end of the clip instead: the last fraction of a second can be cut, more on a slow board. Stopping a video still adds time to each rotation, so a playlist with videos still drifts, more slowly than before. In the project's testing on a Pi 2 with a mixed playlist, drift went from about 36 seconds an hour to about 28.5.

Players still don't line up with each other: each one starts its playlist when it boots.

Anthias 2026.10.0: The upgrade script no longer runs a Pi 2 or Pi 3 out of memory, and other fixes

Fri, 16 Oct 2026 00:00:00 +0000

Fixes

Running bin/upgrade_containers.sh yourself on a board with less than 1.5 GiB of memory, such as a Pi 2 or Pi 3, now stops the viewer and the background worker before pulling new images, and starts them again on the new ones. Pulling with the viewer running could use up memory and swap and reset the board halfway through. The screen shows no content during the pull, and the web interface stays up. Upgrades through the installer already stopped every container first.
A memory card whose product name contains a byte that isn't valid UTF-8 no longer stops storage health monitoring, which the storage card on the System Info page relies on.
Starting the viewer no longer logs /proc/<pid>/oom_score_adj: No such file or directory.

For contributors

A test fails the build if a background task has a hard time limit without a soft one below it, and another fails it if a module the viewer imports pulls in celery, which the viewer image doesn't ship.
New tests cover the soft time limit handling, the database readiness wait, the viewer's startup and respawn paths, and SQLite backup and restore.

Python, JavaScript and GitHub Actions dependencies are updated.

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.

Anthias 2026.08.2: A warning on every page when a Raspberry Pi isn't getting enough power

Mon, 17 Aug 2026 00:00:00 +0000

A Raspberry Pi on a weak power supply freezes, glitches and shows stray text along the edge of the screen, and nothing on the player said why. Left alone, a weak supply can also corrupt the memory card until the player stops starting up. From Anthias 2026.08.2, the web interface tells you when it's happening, with a banner at the top of every page, the Schedule page included.

The banner has 2 forms:

"This player isn't getting enough power" while the voltage is too low right now.
"This player briefly lost power" when it dropped earlier and is steady again. It says how many times that happened since the player last restarted, and how long ago the last one was.

Under "What to do", the first step is the official Raspberry Pi power supply for your model, which the banner calls the fix in almost every case. Then the cable that came with it, unplugging USB drives, hubs and keyboards powered by the player, and not running the player from a TV's USB socket or a phone charger.

You can't dismiss the banner, since a weak supply keeps damaging the card while it's ignored. It goes away once the player restarts with a supply that holds. When a storage warning shows as well, the power banner comes first, because a bad supply is one of the main reasons cards fail.

System Info has a new "Power supply" card with the same verdict, how many drops there have been since the last restart, and when the first and most recent were.

Which players show it

Raspberry Pi players: the Pi 2, Pi 3, Pi 4 and Pi 5 images, installed with the installer or through balena. Anthias reads the kernel's rpi_volt sensor under /sys/class/hwmon, which works from inside the containers, so it needs no host agent. On x86 and other boards that have no such sensor, the "Power supply" card says "Not monitored", and no banner appears.

The kernel wakes Anthias whenever the reading changes, and every page load reads the sensor again, so the banner is current when you open the page. On current Raspberry Pi kernels, vcgencmd get_throttled no longer keeps a record of earlier drops, so Anthias counts them itself. The count starts over at every reboot.

For developers

/api/v2/info has a new under_voltage object with supported, active, seen_since_boot, first_seen, last_seen and count. Check supported first: when it's false, the device has no sensor and the other fields carry no information. bin/collect_debug.sh saves the /api/v2/info response in the bundle as api-info.json, and also reads the sensor and the kernel's under-voltage messages directly, for a player too broken to answer.

Anthias 2026.08.2: The web interface warns when a player's storage is failing or full

Mon, 17 Aug 2026 00:00:00 +0000

A memory card that is going bad rarely says so. The screen keeps playing what it already has, so nothing looks wrong from the front, while uploads, schedule changes and settings quietly stop sticking. From Anthias 2026.08.2, the player checks the storage it runs from and shows a banner at the top of every page of the web interface when something is wrong. Like the power warning, you can't dismiss it, and when both show, it sits under the power one.

The banner names the problem, because each one has a different fix:

"This player has run out of space": the storage is full. This one isn't a hardware fault, and the advice is to delete content you no longer need from the Schedule page. Videos are usually what filled it.
"This player has stopped saving changes": the storage has switched to read-only. The screen keeps playing, but anything you change is lost at the next restart.
"This player can't save anything": Anthias couldn't save a small test file, or read back something different from what it wrote.
"The memory card is returning errors": storage errors since the player last restarted.
"The memory card has recorded errors": errors the filesystem logged earlier, which it keeps across reboots. Saving still works.
"This player's storage is wearing out": built-in storage (eMMC) or an SSD reports that it's near the end of its rated life, for example with 80 percent or more of its rated writes used. A plain SD card doesn't report this.
"The drive is developing bad spots": an SSD or hard drive reports blocks that have gone bad.

The wording follows the hardware: "memory card" for an SD card, "built-in storage" for eMMC and "drive" for an SSD or hard drive. So does the advice. Every warning except a full disk says to take a backup from Settings while the storage can still be read, and to replace the card or drive. For an SD card it adds to buy an A1 or A2 card from a brand you recognize. Built-in eMMC is soldered to the board, so there the advice is to plan to replace the player.

System Info has a new storage card next to the "Disk" card, with the same verdict, plus the details for a support conversation: the card's maker, model and manufacture date, the filesystem's error count, how much has been written to it, the result of the last write test and, on drives that report it, SMART health, bad blocks and wear.

How it checks

An SD card has no health register, so Anthias combines what the kernel does expose: the ext4 error counters stored in the filesystem, a test file it writes and reads back, and the wear registers on eMMC. It reads the counters every minute, and on every page load, and writes the test file every 15 minutes. A full disk shows up through that test, so the "run out of space" banner can take up to 15 minutes to appear. All of this works from inside the containers, so balena installs get the warnings too.

On the x86, arm64 and Raspberry Pi 5 images, which can run from an SSD, the viewer also reads the drive's SMART data with smartctl once an hour. The viewer runs as an unprivileged user, so its image has a sudoers rule that lets that user run only smartctl --json -H -A -i on a device under /dev/.

In Anthias 2026.08.2, a memory card whose product name isn't valid UTF-8 stopped storage monitoring from starting at all. Anthias 2026.10.0 fixes that.

For developers

/api/v2/info has a new storage object. Check supported first, then branch on status, one of ok, wear, errors, full, failing or unknown. errors_count covers the life of the filesystem and survives reboots. errors_new and the write test fields reset when the player reboots. bin/collect_debug.sh adds a storage.txt to the bundle with block devices, mount flags, the ext4 error counters, card identity, SMART output and the kernel's storage errors.

Anthias 2026.08.2: Settings flags a player that skips SSL certificate checks, and other fixes

Mon, 17 Aug 2026 00:00:00 +0000

Fixes

Notifications in the web interface show their success, error or info icon, and the Load Average card on System Info shows its icon when the load is steady. Both spaces were empty.
In the Edit asset dialog for a web page, the "Auto-refresh interval (seconds)" and "Custom HTTP headers" labels no longer sit on top of their example text.
In Settings > Import content, each platform's import button sits beside its description instead of under it.
The "Try again" and "Copy ffmpeg command" buttons in the asset dialog have a button style. They showed without one.

Improvements

When "Verify SSL certificates" is off, Settings shows a "Not secure" badge next to it, so a player that skips certificate checks is easy to spot. It appears as soon as you switch the setting off, before you save.
The disk chart on System Info no longer shows used space in red. It uses the same colors as the memory chart, and a storage problem shows up in the new storage card instead.
The import pages under Settings > Import content use the web interface's own colors. Their progress bar was a blue used nowhere else.
On a board with little memory, the "Low-RAM mode" note on System Info's Memory card is in a darker amber that's easier to read on white.

For contributors

The web interface's colors, fonts and sizes are defined once, in src/anthias_server/app/static/src/tailwind.css, with dark values in css/theme-dark.css next to it. The older SCSS copy, which had been overriding them, is gone, and tests fail if one comes back.
A design-system page at /_design/ shows every color and component, in light and dark. It exists only in development builds and tests (DEBUG or IS_TEST), so production images don't have the route.
bin/shoot_pages.py screenshots the web interface pages in both themes and at several window sizes, without the Docker stack.
The host agent lists network addresses through the kernel's rtnetlink interface with the Python standard library. The netifaces and netifaces2 packages are gone, and so is python3-netifaces in the viewer image. uv sync --group test works on a plain development machine, where netifaces used to fail to build.
The release and hardware-testing guides for coding agents in .claude/skills add a burn-in run on the test boards before a release is published.
Tests cover the power and storage checks, SMART parsing, the network address listing and the design-system page.

Anthias 2026.08.1: A new display schedule blanks the screen outside opening hours

Fri, 14 Aug 2026 00:00:00 +0000

A screen in an office or a shop stays lit all night and all weekend for nobody. People have asked Anthias for a way to turn it off out of hours since 2012, and some ran their own cron job to do it. Anthias 2026.08.1 adds a display schedule to Settings that switches the screen off at closing time and back on in the morning.

The schedule is off by default, so a player that has always stayed lit keeps doing so after the upgrade. Turn on "Enable schedule" under Settings > Display schedule, then set:

"Turn on at", 08:00 by default.
"Turn off at", 18:00 by default.
The days it runs. If you uncheck every day, it runs every day.

Times are in the player's timezone. An overnight schedule belongs to the day it starts: with 18:00 to 06:00 and only Friday checked, the screen comes on Friday evening and stays on until 06:00 on Saturday.

What the screen does

At each change, Anthias blanks or unblanks the screen itself, and pauses or resumes playback with it. On the Raspberry Pi 5, x86 and arm64 images the display output is switched off, so the display gets no signal. On the Raspberry Pi 2, 3 and 4 images the viewer shows a black screen instead.

Anthias also sends the HDMI-CEC standby or power-on command to every HDMI port with a CEC display attached. Doing both means a plain monitor goes dark, a TV that obeys CEC goes into standby, and a player with one of each on its 2 ports handles both. You don't need a CEC adapter or a CEC display for the schedule: it isn't hidden on boards without one.

The schedule is checked every minute, so a change lands within about a minute of the time you set. Anthias also repeats the current state about every 10 minutes. That's what puts a black screen back after the viewer restarts in the middle of the night, and it also means that if you switch the screen on by hand during off hours, it goes off again within about 10 minutes.

Turning the schedule off while the screen is off brings the screen back on within a minute.

What to check on your setup

Whether a TV goes into standby is up to the TV. Anthias 2026.08.1 hasn't been tested end to end against a CEC-capable display, so if you rely on a TV powering down, watch it the first evening and report what you see. HDMI-CEC display controls no longer fail on a Raspberry Pi 2, 3 or 4 has the rest of what changed for CEC in this release.

For developers

The schedule is 4 fields on /api/v2/device_settings, readable with GET and writable with PATCH:

display_power_schedule_enabled, a boolean.
display_power_on_time and display_power_off_time, as HH:MM. HH:MM:SS is accepted and stored as HH:MM.
display_power_days, a comma-separated list of weekday numbers from 0 to 6, where Monday is 0. An empty value means every day. Asset play_days counts Monday as 1, so the 2 don't match.

A malformed time or weekday gets a 400 response from the API. In the web form, a malformed time keeps its previous value and shows an error.

Anthias 2026.08.1: HDMI-CEC display controls no longer fail on a Raspberry Pi 2, 3 or 4

Fri, 14 Aug 2026 00:00:00 +0000

If you use Anthias to turn a TV on and off over HDMI, that never worked on a Raspberry Pi 2, 3 or 4, and on a Raspberry Pi 5 only one of the 2 HDMI ports got the command. Anthias 2026.08.1 fixes both, and stops calling an ordinary monitor an error. After upgrading, try it with your TV, because it hasn't been tested end to end with one yet.

Before Anthias 2026.08.1, the HDMI-CEC display controls could only fail on a Raspberry Pi 2, 3 or 4. The "Display Power (CEC)" card on the System Info page read "CEC error", and "Turn display on" and "Turn display off" in Settings failed, even with a TV that supports CEC.

From Anthias 2026.08.1, CEC commands go out on the Raspberry Pi 2, 3, 4 and 5 and the Rock Pi 4. They go to every HDMI port that has a CEC display attached, so a second screen isn't left out. When no port has one, the buttons say "no CEC link on any HDMI port" instead of failing with no reason. Whether the TV then turns on or off is still up to the TV.

System Info tells a plain monitor from a fault

Most desktop monitors don't support CEC, and Anthias used to report that as "CEC error". The "Display Power (CEC)" card now reads:

"True" or "False" when every display that answered is on, or in standby.
"Mixed" when 2 displays disagree, or one is switching.
"No CEC display detected" when nothing answers. That's normal for a plain monitor, not a fault.
"Not available" on a board with no CEC hardware, such as most x86 PCs, as before.
"CEC error" only when Anthias couldn't ask at all.

What to check on your setup

Anthias 2026.08.1 hasn't been tested end to end against a CEC-capable display: no test setup had one. Finding the CEC hardware and telling which ports have a CEC display was checked on a Raspberry Pi 2, 3, 4 and 5, a Rock Pi 4 and an x86 machine. USB CEC adapters haven't been tried. If you use CEC to turn a TV on and off, try it after upgrading and report what you see.

The viewer container now does the CEC work for the whole player, so if the viewer isn't running, the card reads "CEC error" and the buttons fail.

For people who build on Anthias

The images no longer include libcec or cec-client, since Anthias talks to the kernel's CEC devices (/dev/cec*) itself. The viewer container is privileged and already sees them, so the server and Celery containers get no CEC devices: the compose templates drop their /dev/vchiq entries, and bin/upgrade_containers.sh, bin/deploy_to_balena.sh and bin/balena_ota_deploy.sh no longer rewrite the device list per board. Needing no device list is also what lets CEC work on balena installs, though it hasn't been tried on a balena device yet.

On /api/v1/info and /api/v2/info, display_power is still a string or null. Its values are True, False, Mixed, No CEC display detected, Not available, CEC error and, rarely, No CEC adapter. Unknown, which a working adapter with nothing answering used to return, is now No CEC display detected.

Anthias 2026.08.1: Large JPEG and PNG uploads are resized on boards with little RAM

Fri, 14 Aug 2026 00:00:00 +0000

A phone photo is 12 to 50 megapixels, and a 1080p screen shows about 2 of them. From Anthias 2026.08.1, a board with less than 1.5 GB of RAM shrinks a JPEG or PNG upload that has more pixels than a 1920x1080 image down to about that many, keeping its shape. That covers the Raspberry Pi 2, the Pi 3 and 1 GB boards such as a 1 GB Pi 4. A board with more memory leaves your files as they are.

In the project's testing on a 64-bit Raspberry Pi 3, a 6000x4000 photo was stored at 1762x1175, and the viewer used less than half the memory to show it.

Anthias 2026.08.0 started doing this for images it converts to WebP on upload, such as HEIC and TIFF. JPEG and PNG skip that conversion, so until this release they stayed at full size.

What happens to your file

It keeps its format, and the asset shows as processing until the resize is done.
A JPEG is saved again at quality 90. A PNG stays lossless.
A phone photo's rotation is applied to the pixels and its EXIF data is dropped, so it stays upright.
GIF, WebP and SVG files aren't resized.

A resized PNG can end up larger on disk than the original. A flat graphic with big areas of one color compresses very well at full size and less well once it's scaled down, while a photographic PNG gets smaller. The resize is there to cut the memory the viewer needs to draw the image, so Anthias keeps the resized file either way.

Anthias 2026.08.1: Menu Board's items and World Clock's cities can be set from the Apps tab

Fri, 14 Aug 2026 00:00:00 +0000

Installing Menu Board from the Apps tab in "Add asset" gave you a board with your title and footer and no menu under them. Its items are a list, and the form left out any setting that takes a list, so there was nowhere to type them. World Clock's cities had the same problem.

From Anthias 2026.08.1, a list setting shows as rows, one per item, with the fields for that item, such as a menu entry's section, name and price. "Add" puts in a new row and each row has its own remove button. When you edit an installed app, its saved items load back into the rows.

This closes the gap left when the Apps tab arrived in Anthias 2026.07.1, which couldn't set a list.

Anthias 2026.08.1: A player with nothing to show stops filling its log, and other fixes

Fri, 14 Aug 2026 00:00:00 +0000

Fixes

A player with an empty playlist, or with an asset it can't show, no longer writes the same log line every few seconds. The viewer logs the first time and stays quiet until something changes. The journal on a player is small, and the repeats pushed out the log lines you'd need after a crash.
On the Raspberry Pi 2 and 32-bit Pi 3 images, a display that disappears while the player runs no longer leaves the viewer retrying on a black screen first, which at startup could take several minutes. The viewer gives up on the first failed start and its container restarts, which is what finds the display again.
On the Raspberry Pi 5, x86 and arm64 images, when the viewer restarts itself because it started without seeing a connected display, it logs that as a warning instead of an error, so a recovery that worked no longer sends an error report.

Improvements

Anthias's usage statistics now include the Anthias version, as version_name, next to the commit and branch they already sent. With analytics_opt_out set in the player's config, nothing is sent, as before.
The API reference on the Anthias website is built from the API itself and updates when the API changes. The old copy was missing 9 endpoints, including the display power and viewer endpoints.
The Anthias website has pages on using a Raspberry Pi for digital signage, as an advertising display and as an info screen, a link to the signage app store at signage-apps.com, and a Trust Center link with an FAQ entry on where to get the SBOM. It also says plainly that the Raspberry Pi Imager images are the balenaHub Fleets for Good images, which update over the air.

For contributors

bun run test runs front-end tests that need a page, using happy-dom, starting with the app settings form.
New tests for the CEC code, the display schedule, telemetry, image processing and the viewer's log changes.
The README no longer carries the broken Star History chart or the stale "Issues and Bugs" note.

Django REST framework, uvicorn, Python development tools and the GitHub Actions used in CI, including CodeQL, were updated.

Anthias 2026.08.0: Anthias installs and runs behind an HTTP proxy

Wed, 05 Aug 2026 00:00:00 +0000

If your network only lets a player out through an HTTP proxy, Anthias 2026.08.0 can now be installed and run there. The installer asks for the proxy and sets it up for you. If your player reaches the internet directly, leave that question blank and nothing changes.

Before, someone running Anthias on a PC behind a proxy had to set it by hand for the installer, apt, Docker, the host agent and the containers, one at a time, and a hand-written bypass list could cut the viewer off from the server and blank the screen.

Setting a proxy

Run the installer as usual. It now asks for a proxy URL, for example http://proxy.example.com:3128, and then for any hosts on your network that should skip the proxy. The one URL is used for both HTTP and HTTPS. Leave the first question blank if the player has direct internet access.

If you export HTTP_PROXY, HTTPS_PROXY and NO_PROXY (upper or lower case) before you run the installer, the questions start with those values. On a host that doesn't have whiptail yet, the questions can't appear, so export the variables first.

The installer asks every time it runs, and it doesn't fill in the proxy you gave it last time. When you run it again to upgrade, enter the proxy again or export it first. If you leave the question blank, the installer takes the proxy back out.

Where the proxy applies

The installer's own downloads and the Ansible steps it runs.
apt, through /etc/apt/apt.conf.d/00anthias-proxy, so your own apt runs on the player stay proxied afterward.
The Docker daemon, so it can pull the Anthias images. This adds a systemd drop-in at /etc/systemd/system/docker.service.d/http-proxy.conf and restarts Docker.
The anthias-host-agent service.
The server, viewer and Celery containers, including the web pages the viewer shows on screen.

Anthias keeps the values in /etc/anthias/proxy.env. A proxy URL can carry a username and password, so the file is readable only by root and the Anthias user's group. The installer rewrites it on every run, and it always adds localhost, 127.0.0.1, ::1, anthias-server and redis to the bypass list, so traffic between the Anthias containers never goes through your proxy.

To change the proxy, run the installer again with the new value. To remove it, run the installer with the question left blank and nothing exported: it deletes proxy.env, the apt setting and the Docker drop-in.

The balena images don't use the installer, and this release doesn't cover them.

Anthias 2026.08.0: A TV switched on after the player boots gets a picture on Raspberry Pi 5 and x86

Wed, 05 Aug 2026 00:00:00 +0000

If your TV switches on after the player has started, for example on a power timer, the screen could stay on "No Signal" until someone rebooted the player. From Anthias 2026.08.0 the picture comes up on its own after a short wait. It affects a Raspberry Pi 5, an x86 PC or a board running the generic arm64 image, and there's nothing to set.

On those boards, a player that booted while its TV was off stayed on "No Signal" after the TV came on. The only way out was to restart the viewer container or reboot the player. Anthias 2026.07.2 added a check that restarts the viewer when a display turns up after boot, but it only acted once the display had reported its resolutions to the player. A TV that was plugged in but off at boot never got that far, so the check never fired. From Anthias 2026.08.0 it acts on any connected display that has no picture: after 60 seconds, the viewer container restarts so the display is detected again. In the project's testing on a Pi 5, the first restart brought the picture back, about 70 seconds after the display was connected.

The restarts are capped at 3 per boot. A display that never answers, such as one on a faulty cable, gets 3 attempts. Then the viewer logs that it gave up and stops restarting, so a failed screen can't keep the viewer cycling all night. The count starts over when the display comes up, when it's unplugged, or when the player reboots.

The Raspberry Pi 2, 3 and 4 images use a different display path, and this change doesn't affect them.

Anthias 2026.08.0: Portrait photos from a phone or camera display upright

Wed, 05 Aug 2026 00:00:00 +0000

A phone or camera usually saves a portrait photo as a landscape image, with a tag that says to turn it 90 degrees when it's shown. Anthias ignored that tag on JPEG and AVIF files, so those photos appeared sideways on the screen.

From Anthias 2026.08.0 they display upright:

A JPEG is turned by the viewer as it draws the photo, so JPEGs you uploaded before the upgrade come out upright too.
An AVIF photo is turned while Anthias converts it to WebP on upload. An AVIF you uploaded before the upgrade was converted sideways and stays that way, so upload it again.

HEIC photos, the format an iPhone saves, and TIFF files already displayed upright.

Anthias 2026.08.0: URL and web page content loads after a cold boot on x86

Wed, 05 Aug 2026 00:00:00 +0000

If your Anthias player is a PC rather than a Raspberry Pi, web pages could go missing from its playlist after it was switched on, while images and videos kept playing. Upgrading to Anthias 2026.08.0 with the installer fixes it. On a Debian 13 PC installed from the netinst image, read the known problem below before you run the installer.

On some x86 players, web pages and other URL content were skipped after a cold boot, while images and videos stored on the player played fine. The viewer log showed Asset ... is not available, skipping, and only restarting Docker or the Anthias containers brought the content back, until the next reboot.

The containers could start before the player had its DNS servers, and they kept that empty DNS setup until they were recreated. The project reproduced it on Debian 13, on a PC whose network card is set up by Debian's own network configuration rather than NetworkManager.

From Anthias 2026.08.0, the installer sets up systemd-resolved on x86 and makes /etc/resolv.conf a link to /run/systemd/resolve/stub-resolv.conf, a local resolver at 127.0.0.53 that the containers can always reach. Run the installer to upgrade and the change is made. Raspberry Pi and arm64 installs don't get it.

The installer makes this change even if you chose not to let Anthias manage the network, and it replaces an /etc/resolv.conf you manage yourself.

Known problem: DNS can stop while the installer runs

On a Debian 13 PC installed from the netinst image, where dhcpcd sets up the network, the switch to systemd-resolved can leave the player with no working DNS. The installer then stops at its next download with Temporary failure in name resolution. In the project's testing, name lookups on such a PC also stopped again some minutes after a reboot. The installer still does this as of Anthias 2026.10.0.

Before you run the installer on such a PC, give systemd-resolved a fallback DNS server, such as your router's address:

sudo mkdir -p /etc/systemd/resolved.conf.d
printf '[Resolve]\nFallbackDNS=<your router IP>\n' | sudo tee /etc/systemd/resolved.conf.d/99-fallback.conf

If the installer already stopped, do the same, run sudo systemctl restart systemd-resolved, and run the installer again.

Anthias 2026.08.0: Large HEIC, TIFF and AVIF photos no longer reboot boards with little memory, and other fixes

Wed, 05 Aug 2026 00:00:00 +0000

Fixes

On boards with less than 1.5 GB of RAM, such as the Raspberry Pi 2 and 3, a HEIC, TIFF, AVIF or other photo that Anthias converts to WebP on upload is first shrunk to fit within the pixel count of 1920x1080, keeping its shape. In the project's testing, a 24 megapixel photo used more memory than the board could give the conversion, and the board rebooted. JPEG and PNG uploads got the same treatment in Anthias 2026.08.1.
On a Raspberry Pi, running the installer from the player's own screen and keyboard blanked the screen partway through and removed the login prompt, which left you locked out if SSH was off. This happened since Anthias 2026.05.1. The install now finishes on screen, and the login prompt is still gone after the reboot at the end, as intended.
While the web interface was open, the server logged a Redis timeout and an Exception in ASGI application error about every 5 seconds. It no longer does.
The API's file_asset, recover and assets/order endpoints answer a request body that's a JSON list instead of an object with a 400 response, instead of a 500.
Running the Ansible playbook yourself on a PC or other board that isn't a Raspberry Pi no longer fails at the step that writes the Raspberry Pi boot settings.

Improvements

When the installer is about to discard your edits to files tracked in the Anthias checkout, it prints a warning first. It still discards them. Untracked files are left alone.
When the Docker repository key is already on the player, the installer no longer downloads it again, so a machine prepared ahead of time doesn't need network access for that step.

For contributors

The Ruff linter now runs its expanded default rule set (about 413 rules, up from 59), and the findings across the codebase were fixed. BLE001 (blind except) stays off on purpose, because the player is meant to degrade rather than crash.
Tests cover the entry point of the GStreamer framebuffer video player used on the Raspberry Pi 2 and 3.
The Anthias website's API page has an overview of the base URL, versioning, authentication and errors, the guide to migrating to Screenly covers what gets migrated and how to troubleshoot it, and broken links across the site are fixed.

Python and front-end dependencies and GitHub Actions were updated.

Anthias 2026.07.4: The Audio output setting decides where sound plays on x86 PCs and arm64 boards

Tue, 28 Jul 2026 00:00:00 +0000

If you run Anthias on a PC or on a board like the Rock Pi 4 and video sound came out of the wrong speakers, the Audio output setting now works there. Pick HDMI or 3.5mm jack in Settings and the sound goes where you chose.

Before, on an x86 PC, or on a board running the arm64 image such as the Rock Pi 4, the Audio output setting did nothing. Video sound came out of whichever output the system had picked as its default, whether you chose HDMI or 3.5mm jack in Settings. On a laptop with HDMI selected, for example, the sound still played through the built-in speakers. From Anthias 2026.07.4, HDMI plays through the HDMI output and 3.5mm jack plays through the analog output.

A laptop or desktop often has HDMI and the analog jack on the same sound card, with only one of them active at a time. When the output you chose isn't the active one, Anthias switches the card over to it. If Anthias can't find a matching output, for example HDMI to a display that doesn't take audio, it plays through the system default as before. Raspberry Pi boards pick their output the same way they did.

If sound still comes from the wrong place, run pactl list short sinks inside the viewer container to see which outputs exist. Anthias matches outputs by name (hdmi, analog, headphone and similar), and when none matches the setting, the viewer logs a warning that lists the outputs it found.

Anthias 2026.07.4: Video plays at full frame rate at 180° on Raspberry Pi 2 and 32-bit Pi 3

Tue, 28 Jul 2026 00:00:00 +0000

On a Raspberry Pi 2, or a Raspberry Pi 3 running the 32-bit image, video with Screen rotation set to Landscape, inverted (180°) played at about 2 frames per second, because the board turned every frame in software. From Anthias 2026.07.4 the board's video hardware flips the picture instead. In the project's testing on a Pi 2 with a 1080p, 30 frames per second video, that took playback from about 2 to about 27 frames per second, the same as with no rotation.

Portrait is different. The video hardware on these boards can flip a picture but can't turn it by a quarter, so Portrait (90°) and Portrait, inverted (270°) still go through the software path. The picture is right, but 1080p video plays at about 2 frames per second on a Pi 2. Images and web pages rotate with no such cost. For portrait video, use a Raspberry Pi 4 or 5. The board notes in docs/board-enablement.md now say the same.

Anthias 2026.07.4: Images added from a URL preview and download in the web interface, and other fixes

Tue, 28 Jul 2026 00:00:00 +0000

Fixes

Previewing or downloading an image added from a URL showed nothing in the web interface. Both now open the image from its own address.
When sqlite3 wasn't installed on the host, bin/collect_debug.sh put a Python error in its report where the asset count should be. It now reads the database inside the server container, and the report lists each asset with whether Anthias could reach it.

Improvements

The Anthias website answers "Is Anthias the same as Screenly OSE?", and the page data search engines read no longer wraps titles and answers in extra quote marks.

For contributors

The settings-save tests write to a temporary config file instead of ~/.anthias/anthias.conf, so they no longer change the defaults that later tests read when both test suites share a data volume.
CLAUDE.md describes the current layout of the code, and a .claude/skills folder adds notes for AI coding assistants on the boards, the viewer, testing on real hardware and cutting a release.
Dependabot no longer proposes pillow-heif 1.5 or newer. It can't be built for the 32-bit pi2 and pi3 images against the libheif in Debian Trixie, so pillow-heif stays at 1.4.0.
The Marketing Screenshots workflow runs from the branch you pick in GitHub when you start it by hand. Its separate ref input is gone.
Dependencies and GitHub Actions updated.

Anthias 2026.07.3: Screen rotation turns content the same way on every board

Thu, 16 Jul 2026 00:00:00 +0000

From Anthias 2026.07.3, each "Screen rotation" choice turns the picture the same way on every board. "Portrait (90°)" turns it a quarter turn clockwise and "Portrait, inverted (270°)" a quarter turn anticlockwise, and images, web pages, video and streams all turn together.

Before, the direction depended on the board. A 32-bit Raspberry Pi 2 or 3 turned video clockwise for "Portrait (90°)", while a Raspberry Pi 3 running the 64-bit image, a Pi 4, a Pi 5, a PC and generic arm64 boards turned the picture anticlockwise for the same setting.

If you have a portrait screen on a Raspberry Pi 3 running the 64-bit image, a Pi 4, a Pi 5, a PC or a generic arm64 board such as the Rock Pi 4: after upgrading to Anthias 2026.07.3, the picture shows upside down. In the web interface, open Settings and, under "Display & playback", switch "Screen rotation" from "Portrait (90°)" to "Portrait, inverted (270°)", or the other way round. If you set it through the API, swap screen_rotation between 90 and 270. "Landscape (0°)" and "Landscape, inverted (180°)" look the same as before, and a 32-bit Raspberry Pi 2 or 3 needs no change.

Images and web pages on a 32-bit Raspberry Pi 2 or 3

On a Raspberry Pi 2 or 3 running a 32-bit image, only video followed "Screen rotation", as the 2026.05.1 entry that introduced the setting described. Images and web pages stayed upright whatever you picked. From Anthias 2026.07.3 they turn at 90°, 180° and 270°, in the same direction as video.

Rotated video on these boards still played at only a few frames per second in this release. Anthias 2026.07.4 brought 180° up to full speed.

Video on a 64-bit Raspberry Pi 3

On a Raspberry Pi 3 running the 64-bit image (pi3-64), video ignored "Screen rotation" and stayed upright while images and web pages turned. That started when Anthias 2026.07.2 brought hardware video to this board. Video now turns with everything else.

At 180°, video still plays at full frame rate. This board's video hardware can't turn a picture by a quarter, so at 90° and 270° video plays through a software path instead: about 9 to 10 frames per second for 1080p in the project's testing. For portrait video, a Raspberry Pi 4 or 5 is the better board.

Anthias 2026.07.3: Anthias container images come with signed build provenance

Thu, 16 Jul 2026 00:00:00 +0000

This is for people who check where software comes from before they run it, such as a security team. Nothing changes on your screens and you don't need to do anything, but you can now confirm with 1 command that the software on a player was built by the Anthias project itself.

An Anthias player runs 3 containers, server, viewer and redis, pulled from GitHub Container Registry, with a copy of each image on Docker Hub. From Anthias 2026.07.3, every one of those images, for every board, is published with a signed build provenance attestation. It records the repository, workflow and commit that built the image, so you can check that an image came from the Anthias build before you run it.

Check an image with the GitHub CLI:

gh attestation verify \
 oci://ghcr.io/screenly/anthias-server:<short-hash>-<board> \
 --repo Screenly/Anthias

<board> is one of pi2, pi3, pi3-64, pi4-64, pi5, x86 or arm64. A release's short hash is in the docker-tag file attached to its GitHub release: for 2026.07.3 it's a782add. Put anthias-viewer or anthias-redis in place of anthias-server to check the other 2.

The latest-<board> tags point at the same images and pass the same check. So does the Docker Hub copy, oci://docker.io/screenly/anthias-server:<short-hash>-<board>, because the attestation belongs to the image itself rather than to one registry.

Images built for earlier releases have no attestation. The disk images on the release page aren't covered either: check those against the .sha256 file published next to each one.

Anthias 2026.07.3: The Anthias boot splash shows on a Raspberry Pi 2

Thu, 16 Jul 2026 00:00:00 +0000

On a Raspberry Pi 2 installed with the install script, the screen showed plain text on black while the board booted, not the Anthias splash. The boot splash only waited 8 seconds for a display to appear, and on the Pi 2 the project tested, the display came up about 14 seconds into boot. By then the splash had settled on text. It now waits up to 30 seconds, so the Anthias splash appears.

The fix arrives when you upgrade with bin/run_upgrade.sh, which runs the installer again, and takes effect at the next reboot. Players installed from a disk image or Raspberry Pi Imager run balenaOS, which the installer doesn't set up, so this change doesn't touch them.

For contributors

The wait is DeviceTimeout=30 in the Plymouth config the splashscreen Ansible role installs. Plymouth reads its theme and settings from the copy in the initramfs, so the role now rebuilds the initramfs once, after every file is in place, instead of partway through.

Anthias 2026.07.3: App settings use your browser's date and time pickers, and other improvements

Thu, 16 Jul 2026 00:00:00 +0000

Fixes

Anthias 2026.07.3 reports itself as 2026.07.3 in System Info. The previous release reported itself as 2026.07.1.

Improvements

An app setting that holds a date, a time or both, like the Timer app's "Target date & time", opens your browser's date and time picker instead of a text box you had to type an ISO 8601 value into. It's there when you add an app and when you edit one.
The install guide and the website's get-started page recommend Raspberry Pi Imager for most people. The one-line install script is marked as advanced, and the guide shows how to download it and read it before you run it.
The hardware table on the website's get-started page lists the Raspberry Pi 3 Model A+ as not recommended: its 512 MB of RAM is too little for Anthias. Pick a board with at least 1 GB, a Pi 3 Model B or newer.

For contributors

The SBOM workflow adds an SBOM for the website's dependencies, alongside the JavaScript and Python ones, and runs for release tags only. Each SBOM is still uploaded to sbomify and attested, and is now filed under its Anthias release there.
Dependabot uses the uv ecosystem for Python, so uv.lock is updated together with pyproject.toml, and it no longer proposes Django major upgrades in the grouped Python update.
Dependencies updated, including yt-dlp and Ansible.

Anthias 2026.07.2: Raspberry Pi 2 and 32-bit Pi 3 players stop crashing to a blank screen

Mon, 13 Jul 2026 00:00:00 +0000

If your Raspberry Pi 2 or Raspberry Pi 3 player sat on a blank screen and played nothing, or went blank now and then, upgrading to Anthias 2026.07.2 fixes it. It affects the 32-bit images only.

On a Raspberry Pi 2, or a Raspberry Pi 3 running the 32-bit image (pi2 and pi3), the viewer could crash as it started, restart, and crash again. On some players that happened on every start, so the screen stayed blank and nothing played. On others it happened now and then, and the viewer came back on the next try.

From Anthias 2026.07.2 the viewer runs steadily on these boards. In the project's testing on a Pi 2 and a 32-bit Pi 3, it showed web pages, images and video for hours without a single crash.

The 64-bit images, including the 64-bit Raspberry Pi 3 image (pi3-64), build their web view a different way and don't need this fix.

After the upgrade, System Info still shows 2026.07.1, because this release reports the previous version number.

For contributors

The pi2 and pi3 images don't compile Qt. The image builder downloads a prebuilt Qt 5.15.19 toolchain, QtWebEngine included, from a WebView-v* GitHub release and builds the AnthiasViewer app against it. At this tag, qt5_toolchain_url in tools/image_builder/utils.py points at WebView-v2026.07.1, whose tarballs carry the fix, so a viewer image you build from 2026.07.2 gets it with no other change.

The crash came from the compiler. Debian's armhf gcc turns some struct copies into 64-bit NEON stores that require 8-byte alignment, and QtWebEngine sometimes passes them memory aligned to only 4 bytes. The Cortex-A7 and Cortex-A53 fault on that, and the kernel can't fix up a NEON access, so the viewer dies with Unhandled fault: alignment exception (0x801) in dmesg. src/anthias_webview/build_qt5.sh now builds QtWebEngine's Chromium with arm_use_neon=false and wraps the armhf gcc and g++ with -mno-unaligned-access, so the toolchain no longer contains those stores. The script also runs on Debian Trixie's Python 3.13 now, with shims for the imp, pipes and cgi modules that Chromium 87's build scripts still import.

Anthias 2026.07.2: Anthias imports content from Yodeck, ScreenCloud, piSignage, and Xibo

Mon, 13 Jul 2026 00:00:00 +0000

If you're moving screens to Anthias from another signage platform, Anthias 2026.07.2 can copy your content across for you. Settings has a new Import content section with 4 platforms: Yodeck, ScreenCloud, piSignage, and Xibo (Xibo Cloud or a self-hosted CMS).

Select the button for the platform you're leaving, such as "Import from Yodeck", and paste your credentials for it. Anthias lists the media it finds there. Pick what you want, and Anthias downloads each item onto the player and adds it as an asset, showing the progress of each one. If some fail, you can retry just those.

What you paste depends on the platform. Anthias uses it for this import only and doesn't store it.

Yodeck: an API token, from Account Settings > Advanced Settings > API Tokens.
ScreenCloud: an API token, from Studio > Account Settings > Developer. Anthias works out your region on its own.
piSignage: your account's subdomain, email and password, joined with colons as subdomain:email:password.
Xibo: the CMS address, an API application's client ID and its client secret, separated by spaces.

Images and videos come across from all 4 platforms, up to 5 GiB per file. Web pages come across from Yodeck and ScreenCloud. Anything Anthias can't play stays behind and is listed with the reason: audio, documents, and the built-in widgets some platforms draw themselves (weather, clocks, RSS feeds), since a widget's address only works inside the platform it came from.

Imported assets start playing straight away unless you untick "Enable imported assets so they play immediately". Your existing assets aren't touched, and running an import again skips items that came across the first time.

The piSignage and Xibo imports follow those platforms' API documentation and hadn't been tried against a live account when this release shipped.

From the command line

The same import runs over SSH. --dry-run lists what would be imported without copying anything:

cd ~/anthias
sudo docker compose exec anthias-server \
 python -m anthias_server.manage import_content --provider yodeck --token '<credentials>' --dry-run

--provider takes yodeck, screencloud, pisignage or xibo, and --token takes the same credentials the web interface asks for. Leave out --dry-run to run the import.

Anthias 2026.07.2: A new Timezone setting, and a Device time card on System Info

Mon, 13 Jul 2026 00:00:00 +0000

People have asked since 2023 for a way to see and set the time from the web interface. Anthias 2026.07.2 adds a Timezone setting under Settings > Display & playback. The timezone you pick decides when content with a play window or chosen weekdays plays, and how times are shown across the web interface. A change applies as soon as you save, with no restart.

This matters most on balena installs, where the host runs on UTC and Anthias had no way to follow your local time. It works the same on every install. Leave it on "System default" and Anthias follows the TZ environment variable if the container has one, then the host's timezone, then UTC.

System Info has a new Device time card. It shows the player's date and time in the timezone Anthias is using, with its offset from UTC, and keeps ticking while the page is open. The time comes from the player, not your browser, so a player with a wrong clock shows up straight away instead of looking right on your laptop.

Setting the clock itself, or choosing an NTP server, still happens outside Anthias.

For developers

The choice is stored as timezone in the [main] section of anthias.conf, as an IANA name such as Europe/London. An empty value means "System default". It's also the timezone field of /api/v2/device_settings, and /api/v2/info has a new time object with the player's iso time, timezone and offset. Anthias refuses a name the player's tzdata doesn't have, and a bad value written to the file by hand is ignored rather than stopping the web interface from starting.

Anthias 2026.07.2: Images and web pages on servers with self-signed certificates can play

Mon, 13 Jul 2026 00:00:00 +0000

Images and web pages on an internal server often use a self-signed certificate. Anthias couldn't verify it, so it marked the asset unreachable and skipped it, or the screen stayed blank where the content should be. From Anthias 2026.07.2 you can let them through, for one asset or for the whole player.

For one asset, open it with "Edit" and turn on "Skip SSL verification". The switch shows up when the asset's address starts with https://. For the whole player, go to Settings > Display & playback and turn off "Verify SSL certificates". That switches off certificate checks for every asset, so leave it on unless you need it.

Both cover images and web pages, and the check Anthias runs to see whether an asset is reachable. A video file added by its address is downloaded to the player first, and that download still checks the certificate.

For developers

The v2 asset endpoints have a skip_ssl_verify field. The player-wide setting is verify_ssl in the [viewer] section of anthias.conf, True by default, and verify_ssl in /api/v2/device_settings. Setting it to False in the file used to change nothing, because the check stayed on regardless. It takes effect from this release.

Anthias 2026.07.2: Web page assets can send custom HTTP headers

Mon, 13 Jul 2026 00:00:00 +0000

If a dashboard you'd like on a screen needs a token to open, such as a private Grafana board, you can show it from Anthias 2026.07.2 without making it public. You add the token to the web page asset, and web pages that don't need one work as they did.

Pages like that expect the token in an HTTP header, like a Grafana dashboard that expects an Authorization header. A web page asset can now carry its own HTTP headers, so the page loads on the screen. It was asked for on GitHub in 2025.

Open a web page asset with "Edit" and fill in "Custom HTTP headers", one Name: Value per line, for example Authorization: Bearer <token>. Leave it empty for none.

The headers go only to the asset's own origin: the same scheme, host and port as the address you entered. The page's requests to anywhere else, including a redirect to another site or from https to http, go out without them, so a token can't leak to an ad or analytics server the page loads. An asset can have up to 20 headers. Lines that aren't a valid Name: Value pair are dropped when you save.

For developers

v2 asset responses include custom_headers, an object of header names to values, and you can write it on create and update. Writes are validated strictly: a bad name or value, or more than 20 headers, returns an error instead of being dropped. Only web page assets use it.

Anthias 2026.07.2: Video shows on a 64-bit Raspberry Pi 3 instead of a black screen

Mon, 13 Jul 2026 00:00:00 +0000

If videos on your Raspberry Pi 3 showed a black screen while images and web pages played fine, upgrading to Anthias 2026.07.2 fixes it. It affects a Pi 3 running the 64-bit image.

On that image (pi3-64), video assets could show a black screen. People reported it on Anthias 2026.06.3 and kept seeing it after upgrading.

From Anthias 2026.07.2, video on this board goes through the Pi's own hardware decoder straight to the display, with sound on a separate path so a problem with the audio can't stop the picture. In the project's testing, a 1080p, 30 frames per second H.264 clip played at its full frame rate, with no frames dropped once it was running. H.264 is the only video format Anthias accepts on this board.

When a video's time on screen is longer than the clip, it loops. On this board the pause where it starts over is shorter now, about half what it was in the project's testing, though not gone.

In this release, video on this board ignores the Screen rotation setting and plays landscape. Anthias 2026.07.3 fixes that.

Anthias 2026.07.2: Chunked uploads through the API now carry an upload ID

Mon, 13 Jul 2026 00:00:00 +0000

Anthias used to keep a file that was still uploading under a name based on its file name. Two uploads of files with the same name, at the same time or after an earlier one was interrupted, could end up mixed into one corrupt file. From Anthias 2026.07.2, every upload gets its own temporary file, whatever it's called.

Uploads from the web interface need nothing from you. The change is for integrations that upload through /api/v1/file_asset or /api/v2/file_asset in chunks with a Content-Range header. Anthias can no longer tell from the file name which chunks belong together, so it gives each upload an ID instead:

The response to every upload now includes upload_id.
Send that value as an X-Upload-Id header with every later chunk of the same file, and the chunks are put together as before.
A chunk without X-Upload-Id starts a new upload. A malformed X-Upload-Id gets a 400 response.

If you upload in chunks through the API: read upload_id from the response to the first chunk and send it as X-Upload-Id with each chunk after it. Without it, each chunk is stored on its own and the asset you create from the last chunk's uri comes out broken.

Anthias 2026.07.2: Web page transitions stop flashing another page, and other fixes

Mon, 13 Jul 2026 00:00:00 +0000

Version number

Anthias 2026.07.2 reports itself as 2026.07.1. System Info shows v2026.07.1, so does anthias_version in /api/v2/info, and outside balena the "Update available" badge on System Info stays on until you move to a newer release. You're running 2026.07.2 all the same. Anthias 2026.07.3 reports its own version correctly.

Fixes

On a Raspberry Pi 4 (64-bit), a Raspberry Pi 5, x86 and other boards with 2 GB of RAM or more, moving from one web page to the next could briefly show a different page from the rotation. Every transition now goes straight to the next page. These boards now run one web view instead of two, which frees about 100 MB of memory in the project's testing.
A web page asset with "No cache" turned on could still come from the cache when it came around again. It's now fetched fresh every time it's shown.
On a Raspberry Pi 5, x86 or a generic arm64 board such as the Rock Pi 4, a player that booted with no display plugged in could stay black after you plugged one in. The viewer now restarts itself about a minute after the display appears, and the picture comes up. A display that was plugged in but switched off at boot still stayed black until Anthias 2026.08.0.
The viewer no longer keeps everything the video player prints in memory, only the last 64 KB. Some MP4 files make the video decoder print a warning for every frame, and on a 2 GB Raspberry Pi 4 with large files that output filled the memory and blanked the screen for minutes between assets. A report after this fix says long blank gaps can still happen on such a board.
On boards with less than 1.5 GB of RAM, such as a 1 GB Raspberry Pi 3B+, cycling through web pages could fill the memory until the screen went black. Web pages on those boards now run in Chromium's low-memory mode, and the "Low-RAM mode" note on System Info says so.
An upgrade could stop partway on a board short on memory, at the Ansible step that turns swap off. The upgrade now stops the Anthias containers first, skips turning swap off when memory is tight, and carries on if that step still fails.

Improvements

Selecting several assets and choosing "Edit" also lets you set "No cache" and "Skip asset check", each to on or off, alongside the dates, duration, play times and weekdays it already covered.
The API reference on the Anthias website shows endpoint paths, status codes and field names. It used to show them as 0, 1, 2 and so on.

For contributors

bin/start_viewer.sh is split into a shared script and one per display stack (Wayland, eglfs and linuxfb) under bin/lib/viewer/, with no change in behavior.
The ANTHIAS_LOW_RAM variable for the viewer container is gone, since every board now runs a single web view.
Error reports to Sentry leave out more expected events: requests with a Host header the player doesn't answer to, a browser that disconnects while the web interface is being told about a change or while a file is still downloading, and the warnings about missing or outdated basic-auth credentials that a database upgrade can log. The background task that recovers assets stuck in processing now stops cleanly at its time limit instead of being killed.
The Anthias website publishes llms.txt and llms-full.txt.
More test coverage for the import providers, the viewer and timezone handling.

Dependency updates also went in, among them Pillow, uvicorn and TypeScript, which moved to version 7, plus GitHub Actions.

Anthias 2026.07.1: A new Apps tab for adding ready-made signage apps

Wed, 08 Jul 2026 00:00:00 +0000

A clock in the lobby or a news feed in the break room no longer needs a web page you found and pasted in yourself. Anthias 2026.07.1 adds a third tab, "Apps", to the "Add asset" window, next to "From URL" and "Upload file". It lists the apps in the signage app store, each with an icon, a short description and tags.

Pick an app and fill in its settings, such as a time zone, a location on a map or the feed to show, then select "Add app". The name is filled in for you. For an app you set up by picking from a list, such as the feed in RSS Reader, it's the option you picked, so 2 RSS Reader assets showing different feeds get different names.

An app plays as a web page, so scheduling, durations and ordering on the home page work as they do for any other asset. When an app says how often its page should reload, Anthias reloads it on that schedule. To change an app's settings later, open the asset with "Edit": the "App settings" section has the same form, filled in with your current values.

A setting that takes a list, such as the cities in a world clock, can't be set from Anthias. Some apps then show nothing for it: Menu Board came up with your title and footer but no menu items, until Anthias 2026.08.1.

Where the apps come from

The apps come from Signage Apps, a free catalog you can also browse on its own website. Your browser loads the list from there when you open the tab, so the player doesn't have to reach the store for you to browse it. To show an app, the player loads the app's own address, like any other web page, so it needs to reach that.

Anthias only adds an app whose address is on a domain ending in .srly.io or .signage-apps.com. To point a player at another catalog, such as a store you host yourself, set these environment variables on the server container:

APP_STORE_INDEX_URL, the catalog address, https://signage-apps.com/manifest.json by default
APP_STORE_ALLOWED_HOST_SUFFIXES, a comma-separated list of the domains apps may live on, .srly.io,.signage-apps.com by default

Anthias 2026.07.1: The API checks file paths and YouTube links when you create an asset

Wed, 08 Jul 2026 00:00:00 +0000

Anthias 2026.07.1 protects the files on your player when assets are created through the API. We recommend upgrading every player.

The change is to creating an asset with a POST to /api/v1/assets, /api/v1.1/assets, /api/v1.2/assets or /api/v2/assets. Two kinds of request that used to be accepted are now refused:

A uri that is a file path has to point at a file inside the player's asset folder. A file uploaded through /api/v1/file_asset or /api/v2/file_asset lands there, so uploading a file and then creating the asset from the uri the upload returns works as before.
An asset whose mimetype is youtube_asset needs a YouTube link as its uri: an http or https address on youtube.com, www.youtube.com, m.youtube.com, music.youtube.com or youtu.be.

A refused request gets a 400 response with the reason under uri, either Invalid file path. Failed to add asset. or A youtube_asset URI must point at a YouTube URL.:

{"uri": ["Invalid file path. Failed to add asset."]}

A uri that isn't a valid address now gets a 400 the same way, with Invalid URL. Failed to add asset. under uri. Before, a file path that didn't exist and an invalid address both got a 500 response with the message under error.

If this affects you: if your integration creates assets from files already on the player, upload each file through file_asset first and create the asset from the uri that comes back. If it sends links that aren't YouTube videos as youtube_asset, send them with the mimetype that matches, such as webpage. If it looks for error in a 500 response to spot a bad address, read uri in the 400 response instead.

Anthias 2026.07.1: Raspberry Pi 2 and Pi 3 keep full resolution when the TV turns off and on

Wed, 08 Jul 2026 00:00:00 +0000

If the TV on a Raspberry Pi 2, or on a Raspberry Pi 3 running the 32-bit image, switched itself off and on, for example on a power schedule, the picture could come back at 1024x768 and stay there until someone power-cycled the Pi.

From Anthias 2026.07.1, the viewer watches the Pi's HDMI ports. When a display reconnects, it sets the resolution back to the one the display reports as its preferred mode, so any panel size works, and restarts the viewer once so content is drawn at that size. Expect a short gap in playback when the TV wakes up.

It waits 5 seconds after the display reconnects before it does this. To change that, set ANTHIAS_HOTPLUG_SETTLE_SECONDS on the viewer container.

The same release fixes a related case on these boards: a Pi that started with no display connected could keep waiting for one after you plugged it in. The viewer container now restarts when a display appears and starts showing content.

It checks the HDMI connection every 3 seconds, so a TV that switches off and on again faster than that can be missed, and a receiver or HDMI switch that keeps the connection up while the TV is off hides the change. Only the pi2 and pi3 images run this. On the 64-bit images the viewer keeps control of the display mode itself, and on a 64-bit Raspberry Pi 3 the picture stayed at 1920x1080 through an HDMI unplug in testing.

Anthias 2026.07.1: A very long asset duration no longer crashes the viewer

Wed, 08 Jul 2026 00:00:00 +0000

Typing a very large duration to keep an asset on screen forever, such as 9999999999999 seconds, made the viewer crash when that asset came up, and crash again after every restart while the asset stayed in the schedule.

From Anthias 2026.07.1, a duration can be at most 31,536,000 seconds, which is 1 year:

In the web interface, a longer duration is saved as 1 year. The same goes for "Default duration (seconds)" and "Default streaming duration (seconds)" in Settings.
The API, from v1 to v2, answers a duration below 0 or above 31,536,000 with a 400 response, when creating or updating an asset. On v2 the same limit applies to default_duration and default_streaming_duration in the device settings.
A video file that reports an impossibly long length is given 1 year instead.
An asset saved with a longer duration before you upgrade plays for 1 year at most instead of crashing the viewer.

Anthias 2026.07.1: Video keeps its sound after a reboot, and other fixes

Wed, 08 Jul 2026 00:00:00 +0000

Fixes

On the images with the Qt 6 viewer (the 64-bit Raspberry Pi 3, Pi 4, Pi 5, x86 and arm64), video could play without sound after a reboot or a restart of the viewer container. It has sound after a reboot now.
Restoring a backup through /api/v1/recover or /api/v2/recover no longer loads the whole backup into memory, so a large backup restores on a board with 1 GB of RAM, such as a Raspberry Pi 3, instead of running it out of memory. The restore in Settings > Backup & restore already worked this way.
Uploading to a device whose disk is full now says the disk is full and suggests deleting assets you no longer use. Through the API, file_asset answers with a 507 response. Before, the upload failed with an error that didn't say why.
Chunked uploads to file_asset that arrive out of order are put together correctly. The Content-Range header has to be in the form bytes <start>-<end>/<total>, with a known total. A header that isn't gets a 400 response.
Reboot and shutdown on a balena device keep trying for up to 2 minutes while the balena supervisor is down or restarting, as it is right after an update. Before, they gave up after a few seconds and the device didn't reboot or shut down.
The "Update available" notice on the System Info page, and up_to_date in the API's info endpoint, compare your version with the newest Anthias release. When the newest release on GitHub was something else, such as a WebView toolchain release, the check stopped updating.
The installer no longer stops to ask for a sudo password when your user already has passwordless sudo, as the first user on Raspberry Pi OS does. Unattended installs used to hang at Ansible's BECOME password: prompt.
On a device with no CEC adapter, such as an x86 PC, the "Display Power (CEC)" card on the System Info page shows "Not available" instead of "CEC error". So does display_power in the v2 info endpoint.

Improvements

The 64-bit Raspberry Pi 3 image (pi3-64) ships the Raspberry Pi build of ffmpeg, like the Pi 4, Pi 5 and arm64 images, so H.264 video is decoded by the Pi 3's hardware decoder instead of its CPU. Video on that image could still show a black screen until Anthias 2026.07.2.
The web view on the 32-bit Raspberry Pi 2 and Pi 3 images is built on Qt 5.15.19, up from 5.15.14.
On x86, the "Device model" card on the System Info page shows the board on one line and the CPU on the next, and drops suffixes such as "Corporation" from the maker's name.
The footer of the web interface has "Star on GitHub" and "Review on G2" links. After you add an asset to a device with at least 3 enabled assets of your own, a card asks whether you're enjoying Anthias, with the same 2 links. "Maybe later" hides it for 90 days, following either link hides it for good, and the choice is saved on the player, so it holds in every browser.
The guide to moving assets to Screenly walks through the Migrate to Screenly page in Settings, with no SSH or script.
The Anthias website and install docs point to Raspberry Pi Imager as the quickest way to install on any Raspberry Pi, the Pi 5 included, under Other specific-purpose OS > Digital signage and kiosks > Anthias. The get-started page lists the 64-bit Raspberry Pi 3 as supported instead of in maintenance.

For contributors

bun run test runs TypeScript unit tests with bun test, starting with how the Apps tab builds an app's address and name.
bin/rebuild_qt5_toolchain.sh builds Qt 5.15.19, keeps the QtWebEngine build to MAKE_CORES parallel jobs so it doesn't run the build machine out of memory, and reads CI's public build cache.
Error reports to Sentry leave out expected events: an upload that isn't a valid backup, a failed YouTube or video download, a device with no working DNS, a jump to an asset that was deleted or is still processing, and the background worker briefly losing Redis.

Anthias 2026.07.0: Bulk actions for assets, and uploads of several files at once

Thu, 02 Jul 2026 00:00:00 +0000

Changing the schedule of 40 assets used to mean opening "Edit asset" 40 times, and people have asked on the forum for a way around that for years. From Anthias 2026.07.0, every row on the home page has a checkbox, and the header of each list, "Enabled" and "Inactive", has one that selects the whole list. Once something is selected, a bar shows how many assets you picked, with these actions:

"Enable" and "Disable" move the selected assets between the 2 lists.
"Edit" changes the schedule of all of them at once.
"Delete" removes them all. Deleting can't be undone.

Editing a selection

The "Edit" dialog has 4 groups of settings, each with its own switch: "Start & end dates", "Duration", "Play from / until times" and "Days of week". Only the groups you switch on are changed. Everything else stays as it is on each asset, so changing the duration of 12 assets leaves their dates alone. "No cache" and "Skip asset check" joined the dialog in Anthias 2026.07.2.

Duration doesn't apply to videos, which keep their own length. Switching on "Play from / until times" and leaving both times empty removes the time window, so the assets play all day.

Uploading several files at once

In Add asset > Upload file you can pick several files again, as you could before the web interface was redesigned in Anthias 2026.05.0, or drop them on the upload area. They upload one after another, and the dialog shows which file it's on, such as "File 2 of 5", along with the progress of the current one.

Anthias 2026.07.0: A Prefer dark mode setting shows web pages in dark colors

Thu, 02 Jul 2026 00:00:00 +0000

Anthias 2026.07.0 adds a "Prefer dark mode" switch to Settings. Turn it on and the viewer shows the web pages in your playlist in dark colors, with no change to the pages themselves.

The darkening is automatic, so it also applies to pages that were never designed with a dark theme. Check how your own pages look with it on before you leave it that way.

The setting is off by default. Saving it restarts the viewer's web view, so the change shows on screen without a reboot. Images and videos aren't affected.

For developers

The setting is the prefer_dark_mode field of /api/v2/device_settings, which you can read with GET and change with PATCH. The viewer passes it to the web view as ANTHIAS_PREFER_DARK_MODE=1, which turns on Chromium's automatic dark mode (--blink-settings=forceDarkModeEnabled=true).

Anthias 2026.07.0: New blank and unblank commands turn a screen dark and wake it

Thu, 02 Jul 2026 00:00:00 +0000

From Anthias 2026.07.0 you can turn a screen dark outside opening hours or during a meeting, then wake it again, and it works with any display. There's no button for it in the web interface, so it's for people who can send a command to the player's API, for example from a script.

It's 2 new commands for the viewer, blank and unblank. Until now the only way to do that from Anthias was the experimental HDMI-CEC controls, which work only with a TV that accepts CEC commands.

blank pauses the playlist and turns the screen dark.
unblank turns the screen on and resumes the playlist. Sending play while the screen is blank does the same.

What dark means depends on the board. On x86, Raspberry Pi 5 and generic arm64 boards such as the Rock Pi 4, blank switches off the video signal on every connected output, so a monitor goes into standby. On the Raspberry Pi 2, 3 and 4, Anthias can't switch the output off, so it shows a black image instead and the display stays on.

There's no button for these commands in the web interface. Send them through the API's playback control endpoint, the one that takes next and previous, with the same authentication as any other API call:

curl http://<device-ip>/api/v2/assets/control/blank
curl http://<device-ip>/api/v2/assets/control/unblank

The API reference lists only next, previous and asset for this endpoint, but it passes any command on to the viewer.

Anthias 2026.07.0: Screen rotation turns the display on Raspberry Pi 5 and generic arm64 boards

Thu, 02 Jul 2026 00:00:00 +0000

On a Raspberry Pi 5, picking a value in Settings > "Screen rotation" saved without complaint and left the picture as it was, as the 2026.05.1 entry that introduced the setting described. From Anthias 2026.07.0, "Portrait (90°)", "Landscape, inverted (180°)" and "Portrait, inverted (270°)" turn the whole display on a Raspberry Pi 5, and the change applies as soon as you save, with no reboot. In this release 90° and 270° turn the picture the opposite way to a 32-bit Raspberry Pi 2 or 3; Anthias 2026.07.3 makes every board turn the same way.

The same fix covers generic arm64 boards such as the Rock Pi 4, which run the viewer the same way as the Pi 5.