Anthias 2026.06.1 | Screenly

Anthias 2026.06.1: Balena devices from before the Anthias rename keep or recover their playlist on upgrade

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

From Anthias 2026.06.1, a balena device installed before the Screenly to Anthias rename keeps its playlist and content when it upgrades. A device that already lost them gets them back when it starts 2026.06.1.

Before, such a device could come up with an empty playlist after an upgrade, and many did when Anthias 2026.05.2 rolled out. Nothing had been deleted. Its data was still under /data/.screenly and /data/screenly_assets, but Anthias reads /data/.anthias and /data/anthias_assets, so it started with a new, empty database. Raspberry Pi OS and Debian installs weren't affected, because the installer and the upgrade script already rename those folders.

Now the containers run that same migration against /data every time they start:

On a device that hasn't been migrated yet, the configuration, database and content move to the anthias names, and the paths inside anthias.conf are rewritten to match.
On a device that already came up empty, if anthias.db has no content and the old screenly.db does, the old database is copied into place. The empty one is kept as anthias.db.emptybak.<timestamp>. If anthias_assets is empty too, it becomes a link to the old media folder.

Anthias 2026.06.0 already included this migration, but inside the containers it stopped with an error before doing anything, so it takes effect from 2026.06.1. You don't need to do anything. The recovery only replaces a database with no content in it, so if you added content to an affected device after the upgrade, nothing is replaced, and the old database stays at /data/.screenly/screenly.db.

Anthias 2026.06.1: Smoother video on Raspberry Pi 4 and Pi 5

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

Video on a Raspberry Pi 4 or Pi 5 plays smoothly in Anthias 2026.06.1. Since the viewer started playing video itself in 2026.05.1, these boards decoded video without trouble but only got 8 to 12 frames per second onto the screen, so video looked choppy.

In the project's testing with a 1080p, 30 fps clip:

Board	Frames per second on screen	Viewer CPU use
Raspberry Pi 4	8.3 before, 30 now	about 115% before, 64% now
Raspberry Pi 5	11.7 before, 26.6 now	about 155% before, 13% now

The old path copied every frame from the GPU back to the CPU before drawing it. Frames now stay on the GPU until they're on the screen. x86 and generic arm64 boards use the same viewer, but the project measured the change on the Pi 4 and Pi 5 only. The Pi 4 decodes H.264 in hardware up to 1080p; a 4K H.264 file still decodes in software, which uses every core and drops frames.

If you read the viewer's playback log, /data/.anthias/playback-stats.log, the SAMPLE, END_FILE and STOP lines now have a frames-rendered field next to frames-delivered. frames-delivered counts frames the decoder handed over, and frames-rendered counts how often the picture was drawn to the screen, so a big gap between them means the screen isn't keeping up. Fields are key=value, and the new one sits in the middle of each line, so a script that reads them by position needs updating.

Anthias 2026.06.1: Raspberry Pi 2 and Pi 3 play video instead of a black screen

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

From Anthias 2026.06.1, video plays on a Raspberry Pi 2 or Pi 3. Before, the screen stayed black for the length of every video, while the viewer log said it was showing it:

Showing asset ... (video)

Images and web pages displayed as usual. This had been the case since the Pi 2 and Pi 3 images moved to Debian Bookworm in 2024, whatever OS version the Pi ran.

These boards now play video with GStreamer, and the Pi's video hardware does the heavy work: it decodes the H.264, then scales and converts the picture for the screen. VLC and the python-vlc package are no longer in the Pi 2 and Pi 3 image. In the project's testing on a Pi 3, this pipeline handled 1080p video at about 40 frames per second with no dropped frames, more than a 30 fps clip needs.

Uploads to these boards were already limited to H.264, the codec this hardware decodes. Video follows the "Screen rotation" setting, but rotated 1080p video plays at only 1 or 2 frames per second on these boards. Anthias 2026.07.4 speeds up 180°; 90° and 270° stay slow.

Anthias 2026.06.1: Screen rotation turns web pages and images on Raspberry Pi 4

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

From Anthias 2026.06.1, the "Screen rotation" setting on the web interface's Settings page turns the whole display on a Raspberry Pi 4. Web pages, images and video all turn together. In this release, 90° and 270° turn a Pi 4 the opposite way to a 32-bit Raspberry Pi 2 or 3; Anthias 2026.07.3 makes every board turn the same way.

Before, only video turned on a Pi 4. Web pages and images stayed in landscape whatever you picked, as the 2026.05.1 entry that introduced the setting described.

When you save a new rotation, the viewer restarts with it, with no reboot. On the Pi 4 the viewer sets QT_QPA_EGLFS_ROTATION from the setting each time it starts.

Anthias 2026.06.1: x86 displays no longer freeze on a heavy web page

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

If the screen on an x86 PC, mostly one with Intel graphics, froze on a single frame when the playlist reached a complex web page, Anthias 2026.06.1 fixes it and you don't need to do anything. The screen keeps updating now.

Before, the screen stayed on the last frame it showed while the viewer carried on through the playlist behind it. Only restarting the viewer container brought the display back. The viewer log showed a line like this:

[ERROR] [backend/drm/atomic.c:79] connector HDMI-A-1: Atomic commit failed: Device or resource busy

The x86 viewer now sets WLR_DRM_NO_ATOMIC=1 and WLR_DRM_NO_MODIFIERS=1 by default. They make the display compositor use the older way of updating the screen, which copes when the graphics chip is still busy drawing a page. A single display doesn't need anything the newer way adds.

Both are defaults you can override: set either to 0 in the viewer's environment, for example in a docker-compose.override.yml for the anthias-viewer service. Raspberry Pi and generic arm64 boards are unchanged.

This covers the freeze that leaves Atomic commit failed lines in the log. A screen that freezes with nothing in the log, for example when the network drops while a page is loading, recovers from Anthias 2026.06.3.

Anthias 2026.06.1: Raspberry Pi 2 and Pi 3 viewers retry a crashed start, and other fixes

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

Fixes

On a Raspberry Pi 2 or Pi 3, the viewer often crashed while starting, with malloc(): unaligned tcache chunk detected in the log, and the container restarted in a loop. The viewer now retries the launch itself with a growing delay, up to 30 times at startup, and 3 times when it has to relaunch while content is playing, so playback doesn't stall for minutes. That gets many players going, but on some the crash happens on every launch and the screen stays dark. Anthias 2026.07.2 fixes the crash itself.
A Raspberry Pi 4 with no display attached could still crash-loop with no screens available on balenaOS 2026.x, despite the wait added in 2026.06.0. A virtual output that is always present was counted as a connected screen. It's ignored now, so the Pi 4 waits for a real display.
On x86, Raspberry Pi 5 and generic arm64 boards, the viewer no longer logs A configure is scheduled for an uninitialized xdg_surface when it starts.

Improvements

Device logs are much easier to read. The viewer image no longer turns on Qt debug logging, which had been adding many lines a second to the logs on every board.

For contributors

The C++ viewer tests run with QT_QUICK_BACKEND=software, so the video scene loads on hosts without a usable OpenGL context.
The Qt 6 viewer images install qt6-declarative-dev and the qml6-module-qtquick and qml6-module-qtmultimedia runtime modules, and no longer install libqt6multimediawidgets6. The QML modules aren't linked at build time, so a build without them succeeds, and the viewer then exits at startup with VideoView: QML video scene unavailable in its log.
The Pi 2 and Pi 3 viewer image installs gstreamer1.0-tools and the gstreamer1.0-plugins-base, -plugins-good, -plugins-bad and gstreamer1.0-alsa packages in place of vlc, and python-vlc is gone from the Python dependencies.
docs/board-enablement.md documents the Pi 2 and Pi 3 video path, the startup crash on the 32-bit viewer and the launch retries, and the new Pi 4 and Pi 5 video path.