Anthias 2026.06.3 | Screenly

Anthias 2026.06.3: A 64-bit image for the Raspberry Pi 3, and a balena fleet for the Rock Pi 4

Tue, 09 Jun 2026 00:00:00 +0000

If you have a Raspberry Pi 3 running a 64-bit operating system, or a Radxa Rock Pi 4, there's now an Anthias disk image and a balena fleet made for your board. On a Pi 3 with Raspberry Pi OS, the installer picks the wrong image in this release; that's fixed in Anthias 2026.07.0.

Anthias 2026.06.3 adds a 64-bit Raspberry Pi 3 image, called pi3-64, and a balena fleet and disk image for the Radxa Rock Pi 4 Model B.

Raspberry Pi 3 on a 64-bit OS

A Raspberry Pi 3 can run a 32-bit or a 64-bit operating system. Until now Anthias installed the 32-bit pi3 image on both, with its Qt 5 viewer. From Anthias 2026.06.3, a Pi 3 running a 64-bit OS gets pi3-64 instead, with the Qt 6 viewer the Raspberry Pi 4 uses.

On balena and from the disk image, a 64-bit Pi 3 works from this release. On Raspberry Pi OS, the installer and the upgrade script were meant to choose for you, but in 2026.06.3 they got it wrong in 2 ways:

They chose by the kernel, and 32-bit Raspberry Pi OS starts a 64-bit kernel on a Pi 3 by default. So a Pi 3 on 32-bit Raspberry Pi OS was given pi3-64, and the download failed with no matching manifest for linux/arm/v8.
A new install on a 64-bit OS stopped with Required environment variables missing or invalid, because the install playbook didn't accept pi3-64 yet.

Both are fixed in Anthias 2026.07.0, which chooses by the operating system instead. From then on, a Pi 3 on a 64-bit OS moves to pi3-64 when it upgrades, and a Pi 3 on a 32-bit OS stays on pi3, which is in maintenance mode. To move one to the 64-bit image, flash a 64-bit OS and install Anthias again.

The 64-bit Pi 3 image is in the same places as the others:

a disk image on the release page, anthias-pi3-64
an entry in Raspberry Pi Imager, without the maintenance mode note the 32-bit Pi 2 and Pi 3 entries carry
a balena fleet, screenly_ose/anthias-pi3-64, for the balenaOS device type raspberrypi3-64

As on the 32-bit image, video uploads have to be H.264. HEVC uploads are rejected with a way to convert them. Video on pi3-64 could still show a black screen in this release; Anthias 2026.07.2 fixes that.

Rock Pi 4

The Rock Pi 4 has its own balena fleet, screenly_ose/anthias-rockpi4, and a disk image on the release page, anthias-rockpi4. It runs the generic arm64 containers, so there is no separate Rock Pi 4 build.

Anthias recognizes the board by the model name in its device tree and accepts H.264 and HEVC video uploads on it. On a docker-compose install, a host service reported that model name to the server, but balena installs don't run that service, so a Rock Pi 4 on balena would have had every video upload rejected. The server now reads the device tree itself when nothing has been reported. That also covers a docker-compose install whose host service isn't running. An arm64 board Anthias doesn't recognize still has its video uploads rejected.

Anthias 2026.06.3: Anthias sends error reports to Sentry, and you can turn them off

Tue, 09 Jun 2026 00:00:00 +0000

From Anthias 2026.06.3, the web interface, the background worker and the viewer report errors to Sentry. Reporting is on by default, and the reports go to a Sentry project whose address is built into Anthias, so the maintainers can see which boards and builds fail in the field. Several fixes in this release came from those reports.

What a report contains

A report is sent when one of these services hits an error it doesn't handle, or logs a message at error level. Each one carries:

the error and its stack trace, including the values of the variables in the code where it happened
recent log lines from the same service
for an error in the web interface, the request that caused it: its address, its headers, and the form data it carried, with fields named like passwords or tokens removed
the Anthias version and the build it came from
the device type, such as pi4-64 or x86, the kernel version and architecture, the board model on boards that have a device tree, and whether the device runs on balena

By default a report from the web interface also includes the client's IP address, the signed-in user, and the cookies and other headers that can identify someone. Set analytics_opt_out to True in anthias.conf, the setting that also turns off the usage telemetry, and those are left out. The reports themselves are still sent.

Errors that fix themselves aren't reported, such as Redis restarting or a browser closing a request early.

Turn it off or send it elsewhere

The SENTRY_DSN environment variable on the anthias-server, anthias-celery and anthias-viewer containers decides where reports go. An empty value turns reporting off. The address (DSN) of your own Sentry project sends the reports there instead.

On a docker-compose install, add SENTRY_DSN= to the environment list of those 3 services in ~/anthias/docker-compose.yml and recreate the containers. The upgrade script writes that file again from docker-compose.yml.tmpl on every upgrade, so add the line again after you upgrade. On balena, set SENTRY_DSN as a device variable in balenaCloud.

Anthias 2026.06.3: The web interface and background worker keep running, and tasks no longer fail after upgrades

Tue, 09 Jun 2026 00:00:00 +0000

Several things could stop the web interface or the background worker on a running device, or make tasks fail after every upgrade. Anthias 2026.06.3 fixes each of them.

Legacy time zone names

A device whose /etc/timezone holds an older name such as US/Central crash-looped the web interface and the worker at startup. These names work now, and the device keeps its local time: the images include the legacy time zone data. A name that still can't be found falls back to UTC.

Unreadable files on the SD card

If some of the web interface's own files on the storage couldn't be read, for example after file system damage, the web interface stopped at startup and restarted over and over. It now skips the files it can't read, starts, and logs one error per boot so the fault stays visible.

"Database is locked"

The web interface, the background worker and the viewer share one SQLite database. A write from one of them could make another fail at once with a database is locked error, for example when the viewer read its content list while the worker updated an item. They now wait up to 20 seconds for each other instead of failing, and reads no longer block writes. Databases from older installs switch over the first time they are opened. In this release the change also kept the viewer from noticing content you added or changed until it restarted. Anthias 2026.07.0 fixes that.

Errors after an upgrade or first boot

The worker starts alongside the web interface, which may still be updating the database after an upgrade or on first boot. Tasks that ran in that window failed with no such table: assets. The worker now waits until the database is ready, and logs a warning every 30 seconds while it does. Queued tasks stay queued and run once it starts.

On docker-compose installs, the web interface, worker and viewer also wait for Redis to answer before they start.

Reachability checks

The worker checks whether content that lives at a web address can still be reached. A check that ran past 30 seconds, for example on a slow DNS lookup, was killed along with the worker process running it. A check now gets 60 seconds, and one that runs out of time marks the content as unreachable. Content on your local network, such as an intranet page or another container on the same player, was still marked unreachable and skipped until Anthias 2026.07.0; until then, ANTHIAS_ALLOW_PRIVATE_FETCH=1 on the server and worker lets it through.

Anthias 2026.06.3: The screen recovers when a web page stalls or the webview crashes

Tue, 09 Jun 2026 00:00:00 +0000

The viewer shows images, web pages and video through a separate webview process. When that process stalled or died, a screen could freeze, go dark, or restart the whole viewer container. Anthias 2026.06.3 fixes several ways that happened.

A page that stops loading

If a web page's connection stalled halfway, for example when Wi-Fi dropped without closing the connection, the screen stayed frozen on the previous content until the viewer container restarted. The webview now gives each page 30 seconds to finish loading. If it doesn't, the load is canceled and the same page is requested again. A page that fails right away, such as when the network is down, is retried every 30 seconds too, so a playlist with a single web page recovers once the network is back.

To change the 30 seconds, set ANTHIAS_WEBPAGE_TIMEOUT_S in the viewer container's environment. Values are held between 5 and 3600.

A webview that crashes

On the 32-bit Raspberry Pi 2 and Pi 3 image, the webview can crash while it starts. Anthias 2026.06.1 retries the start, but a crash just after the start, or while the viewer was sending the webview an image or a web page, still restarted the viewer container. On the Raspberry Pi 4 and 5, x86 and arm64, where video plays inside the webview, a webview that died while starting or stopping a video left the screen dark until the next item.

In all these cases the viewer now starts a new webview and sends the same item again. The new webview shows the current item straight away, including when the playlist has only one item, which before stayed blank.

Raspberry Pi 5 and x86

On the boards whose webview runs inside the cage display server (Raspberry Pi 5, x86 and generic arm64 boards), the viewer could start the webview before the display server was ready, for example after the webview restarted. The webview then failed with Failed to create wl_display on every attempt and the viewer container restarted. The viewer now waits for the display server first.

Anthias 2026.06.3: Fixes to video playback on Raspberry Pi 2 and Pi 3

Tue, 09 Jun 2026 00:00:00 +0000

Anthias 2026.06.1 brought video back to the 32-bit Raspberry Pi 2 and Pi 3 image, and it played worse than it should in several ways. Anthias 2026.06.3 fixes them.

A portrait or 4:3 clip was stretched to fill the screen. It is now scaled to fit and centered, with black bars around it.
A clip shorter than its time in the playlist restarts each time it ends, and every restart froze on the last frame for up to several seconds on a Pi 3, so the clip looked cut off or late. It now loops without a gap.
Video at 50 or 60 frames per second stuttered, because these boards draw about 40 frames per second at 1080p. Such clips now play at an even 30 fps. Clips at 30 fps or lower play as they are.
A clip whose sound couldn't play, for example with HDMI audio turned off or an AC3 soundtrack, failed to play at all. It now plays without sound.

The 64-bit boards use a different video player and aren't affected.

Anthias 2026.06.3: Video plays with sound on Raspberry Pi 4 and 5, x86 and arm64

Tue, 09 Jun 2026 00:00:00 +0000

If videos played with no sound on a Raspberry Pi 4 or 5, an x86 PC or another 64-bit ARM board, they have sound from Anthias 2026.06.3, including over HDMI on x86 PCs with common Intel, AMD and Nvidia audio hardware.

The video player on these boards only plays sound through a PulseAudio sound server, and the viewer container didn't run one. Now the viewer container starts its own PulseAudio server at boot, with one output for each sound card the container can see, named after the card, such as alsa_output.vc4hdmi0.hdmi-stereo. On a Raspberry Pi 4, the "Audio output" setting still chooses between "HDMI" and "3.5mm jack". On x86 and generic arm64 boards it has no effect until Anthias 2026.07.4. After a reboot, sound could still go missing until Anthias 2026.07.1.

If a video is still silent, run pactl list short sinks inside the viewer container to see which outputs PulseAudio found.

x86 with HDMI audio

On x86 with "Audio output" set to "HDMI", the viewer asked for a sound device called sysdefault:CARD=HID, which matches no card on common Intel, AMD and Nvidia audio hardware. It now uses default, which is the PulseAudio default output. Generic arm64 boards already worked this way.

Anthias 2026.06.3: Play from and Play until accept 12-hour times, and other fixes

Tue, 09 Jun 2026 00:00:00 +0000

There was no Anthias 2026.06.2 release. Its version number was set in the code but never released, so a device running a build made between 2026.06.1 and this release can report its version as 2026.06.2. This release includes everything since 2026.06.1.

Fixes

Saving an item's "Play from" and "Play until" times in the "Edit asset" window failed with the default 12-hour clock, when "Use 24-hour clock" is off. Times like "02:30 PM" save now. A time that can't be read shows an error message instead of failing, and filling in only one of the 2 times shows a message and saves nothing. Before, it cleared the item's existing time window.
On the 32-bit Raspberry Pi 2 and Pi 3 image, HEIC, HEIF, TIFF, BMP, ICO and TGA image uploads failed to convert, with KeyError: 'WEBP' in the log. They convert now.
A 60 fps video on a Raspberry Pi 4 played slower than real time, at about 0.6 times normal speed in the project's testing, so the end of a clip could be cut off. The viewer now drops frames evenly when the screen can't keep up, which plays a 60 fps clip at about 30 fps. This applies to every board with the Qt 6 viewer. Each line of playback-stats.log gains a frames-forwarded field between frames-delivered and frames-rendered.
The "Display Power (CEC)" card on the System Info page showed None even when the display answered the power query. It now shows True or False where the CEC adapter can be reached. On a Raspberry Pi 2, 3 or 4 the card still showed "CEC error" until Anthias 2026.08.1.
Redis now keeps its data when its container is recreated, as it is on every upgrade. Before, it started empty each time, and the ID the usage telemetry uses for the device was lost, so an upgraded device was counted as a new one.
A device that can't reach GitHub to check for a new Anthias release logs a warning instead of an error, and the warning gives the reason, such as a read timeout, instead of "no data".
When the webview exits, including when the viewer stops it, the viewer no longer logs a crash report for it.

Improvements

When Anthias rejects a video upload, the "Edit asset" window now also lists steps for converting it in HandBrake, a free app for Windows, macOS and Linux, next to the ffmpeg command. The steps use HandBrake's "Fast 1080p30" preset, and on a Raspberry Pi 5, which only plays HEVC, they add a switch to the H.265 encoder.
Backups from Settings > Backup & restore > "Get backup" and from the API use a faster gzip setting. Most of a backup is video and images that are already compressed, so the archive is about the same size. On a large library the download still doesn't start until the archive is built and can time out. Anthias 2026.07.0 fixes that.
Devices on the official balena fleets that were flashed from an old disk image stayed pinned to the release inside it and never received updates. An hourly job now removes that pin, except on devices tagged anthias_keep_pinned. The same job updates balenaOS on up to 5 percent of each fleet's online devices per run, and moves devices already on the latest balenaOS to the newest balena supervisor.

For contributors

Docker image builds pull the BuildKit frontend through mirror.gcr.io instead of Docker Hub, so builds no longer fail on Docker Hub timeouts.
The Docker build matrix, the image builder and the balena workflows include pi3-64, and the balena workflows include rockpi4.
The SBOM workflow works again, and the README's SBOM badge links to the Anthias page on trust.screenly.io.
The development and test compose files wait for Redis to answer before starting the other services. The test stack's worker runs with the test environment, so it uses the test database and doesn't send error reports.
uv.lock matches the pyproject.toml pins again, so uv lock --check passes on a clean checkout.
New tests cover the error report filtering, the database settings, time zone handling, static files, the backup download, webview recovery and the Pi 2 and Pi 3 video player.

Dependency updates also went in, among them uvicorn, the web server, from 0.32.1 to 0.49.0, plus GitHub Actions and Python development tools.