{"product":"anthias","releases":[{"date":"2026-05-31","entries":[{"areas":[],"breaking":false,"content_html":"\u003cp\u003eIf your Raspberry Pi 4, or an x86 PC set up from the balena image, started up to the Anthias splash screen and never got as far as your content, Anthias 2026.05.2 fixes it. You only need to do something if you run your own balena fleet; the settings to check are below.\u003c/p\u003e\n\u003cp\u003eThe 2 boards had different causes.\u003c/p\u003e\n\u003ch2 id=\"x86-on-balena\"\u003ex86 on balena\u003c/h2\u003e\n\u003cp\u003eOn an x86 PC running the balena image, the screen stayed on the splash while the viewer\u0026#39;s logs filled with lines like \u003ccode\u003eCould not make device fd drm master\u003c/code\u003e and \u003ccode\u003eSwapchain for output 'DP-1' failed test\u003c/code\u003e. balenaOS leaves the boot splash (Plymouth) running, and on x86 it kept hold of the display. The viewer now closes the splash before it starts. Installs on Debian aren\u0026#39;t affected, since the splash has already closed there by the time the viewer starts.\u003c/p\u003e\n\u003cp\u003eIf you deploy to your own balena fleet from a compose file you maintain, the \u003ccode\u003eanthias-viewer\u003c/code\u003e service needs 2 additions for this: the environment variable \u003ccode\u003eDBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket\u003c/code\u003e and the label \u003ccode\u003eio.balena.features.dbus: '1'\u003c/code\u003e. \u003ccode\u003edocker-compose.balena.yml.tmpl\u003c/code\u003e in the repository has both.\u003c/p\u003e\n\u003ch2 id=\"raspberry-pi-4\"\u003eRaspberry Pi 4\u003c/h2\u003e\n\u003cp\u003eIn Anthias 2026.05.1, a Raspberry Pi 4 could stay on the splash for 2 reasons.\u003c/p\u003e\n\u003cp\u003eOn some boots, the viewer opened the graphics device that has no display attached (\u003ccode\u003e/dev/dri/card1\u003c/code\u003e when the display was on \u003ccode\u003ecard0\u003c/code\u003e), found no screen, and never started. This happened on Raspberry Pi OS installs as well as on balena. The viewer now looks for the device with the display connector every time it starts, and logs its choice, for example \u003ccode\u003estart_viewer: eglfs DRM device = /dev/dri/card0\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eOn the official Pi 4 balena fleet, the setting that loads the full KMS graphics driver was stored with literal quotes, as \u003ccode\u003e\u0026quot;vc4-kms-v3d\u0026quot;\u003c/code\u003e. The firmware couldn\u0026#39;t read it, so the driver didn\u0026#39;t load and the viewer couldn\u0026#39;t start. The fleet setting is now \u003ccode\u003evc4-kms-v3d\u003c/code\u003e, without quotes, and devices on the fleet restart once to pick it up. If you run your own Pi 4 fleet, check that \u003ccode\u003eBALENA_HOST_CONFIG_dtoverlay\u003c/code\u003e (or the older \u003ccode\u003eRESIN_HOST_CONFIG_dtoverlay\u003c/code\u003e) is \u003ccode\u003evc4-kms-v3d\u003c/code\u003e with no quotes around it.\u003c/p\u003e\n","description":"A Raspberry Pi 4, or an x86 PC running the balena image, could boot to the Anthias splash screen and stay there. Both now get past the splash and play your content.","title":"Raspberry Pi 4 and balena x86 players no longer get stuck on the boot splash","type":"fix","url":"https://www.screenly.io/releases/anthias/2026.05.2/boot-splash-hangs-on-x86-and-raspberry-pi-4/"},{"areas":[],"breaking":false,"content_html":"\u003cp\u003eFrom Anthias 2026.05.2, a device upgraded from an older release starts the viewer normally. Before, some upgraded devices restarted the viewer in a loop, with this line in the logs:\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ePermissionError: [Errno 13] Permission denied: '/data/.anthias/anthias.conf'\u003c/code\u003e\u003c/p\u003e\n\u003cp\u003eThe viewer runs as an unprivileged \u003ccode\u003eviewer\u003c/code\u003e user, and on those devices the configuration folder belonged to root. Now, every time the viewer container starts, it gives the \u003ccode\u003eviewer\u003c/code\u003e user ownership of \u003ccode\u003e/data/.anthias\u003c/code\u003e and everything in it. On a Raspberry Pi OS or Debian install, that folder is \u003ccode\u003e~/.anthias\u003c/code\u003e on the device.\u003c/p\u003e\n\u003cp\u003eYou don\u0026#39;t need to do anything. The fix applies the first time the new release starts.\u003c/p\u003e\n","description":"A device upgraded from an older Anthias release starts the viewer on the first boot of 2026.05.2, instead of restarting it over and over with a PermissionError on anthias.conf.","title":"Upgraded devices no longer crash-loop on a permission error in anthias.conf","type":"fix","url":"https://www.screenly.io/releases/anthias/2026.05.2/upgraded-devices-config-permission-crash-loop/"},{"areas":[],"breaking":false,"content_html":"\u003cp\u003eFrom Anthias 2026.05.2, a Raspberry Pi 2 or Pi 3 that boots without a working display waits for one, and starts the viewer by itself once a screen is connected or switched on, with no restart. That covers a panel that\u0026#39;s powered off, a TV switched on after the Pi, and a TV that\u0026#39;s slow to bring up HDMI.\u003c/p\u003e\n\u003cp\u003eBefore, the viewer couldn\u0026#39;t start in that situation. It logged \u003ccode\u003eUnable to figure out framebuffer device\u003c/code\u003e and \u003ccode\u003eno screens available\u003c/code\u003e, crashed with \u003ccode\u003emalloc(): unaligned tcache chunk detected\u003c/code\u003e, and the container restarted in a loop.\u003c/p\u003e\n\u003cp\u003eWhile it waits, the viewer logs \u003ccode\u003eno framebuffer (/dev/fb0) yet\u003c/code\u003e once, then a reminder every minute.\u003c/p\u003e\n","description":"With no screen connected at boot, or a TV that is slow to wake up, the viewer on a Raspberry Pi 2 or 3 now waits and starts on its own once a display appears.","title":"Raspberry Pi 2 and Pi 3 wait for a display instead of crash-looping","type":"fix","url":"https://www.screenly.io/releases/anthias/2026.05.2/pi-2-and-pi-3-wait-for-a-display/"},{"areas":[],"breaking":false,"content_html":"\u003cp\u003eFrom Anthias 2026.05.2, a device flashed from a disk image gets new stable releases over the air, the same way a device added through balenaHub does. Before, it stayed on the version you downloaded, even after new releases came out, and the installation guide said so.\u003c/p\u003e\n\u003cp\u003eThe image still comes with the release it was built from already on it, so the device doesn\u0026#39;t have to download Anthias before it starts. Once it\u0026#39;s online, it follows the balena fleet for its board and installs each stable release as it\u0026#39;s published.\u003c/p\u003e\n\u003cp\u003eThe first boot needs a network connection. The image doesn\u0026#39;t carry the fleet\u0026#39;s boot settings, such as the graphics driver, so a new device starts on balenaOS defaults, fetches the fleet\u0026#39;s settings and restarts once into them.\u003c/p\u003e\n\u003cp\u003eThis applies to devices flashed from a 2026.05.2 image or newer. Devices on the official fleets that were flashed from an older image catch up too, from \u003ca href=\"/releases/anthias/2026.06.3/fixes-and-improvements/\"\u003eAnthias 2026.06.3\u003c/a\u003e, when an hourly job started clearing their pin. The answer to \u0026quot;How do I update Anthias?\u0026quot; in the FAQ and the disk image section of the installation guide now describe it.\u003c/p\u003e\n","description":"A device flashed from an Anthias 2026.05.2 disk image or newer follows the latest stable release, instead of staying on the version you downloaded.","title":"Devices installed from a disk image now get updates over the air","type":"improvement","url":"https://www.screenly.io/releases/anthias/2026.05.2/disk-images-no-longer-pinned-to-a-release/"},{"areas":[],"breaking":false,"content_html":"\u003ch2 id=\"fixes\"\u003eFixes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eOn a Raspberry Pi 5, the check that reads whether the display is on, which runs every 5 minutes, left a core dump of several megabytes each time. Enough of them could fill the storage and put Anthias services into a restart loop. Neither the check nor the \u0026quot;Turn display on\u0026quot; and \u0026quot;Turn display off\u0026quot; buttons leave core dumps now.\u003c/li\u003e\n\u003cli\u003eThe balena Releases page shows the real version of each Anthias release, such as \u003ccode\u003e2026.5.2\u003c/code\u003e, instead of \u003ccode\u003e0.0.0+revN\u003c/code\u003e. That holds for the official fleets and for fleets you deploy to with \u003ccode\u003ebin/deploy_to_balena.sh\u003c/code\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"improvements\"\u003eImprovements\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eRaspberry Pi 5 devices on the official balena fleet get \u003ccode\u003edtoverlay=vc4-kms-v3d,cma-512\u003c/code\u003e, the line \u003ccode\u003einstall.sh\u003c/code\u003e has written on a Pi 5 \u003ca href=\"/releases/anthias/2026.05.1/quiet-boot-and-boot-config/\"\u003esince Anthias 2026.05.1\u003c/a\u003e. The project\u0026#39;s board notes list it as required for 4K HEVC hardware decoding.\u003c/li\u003e\n\u003cli\u003eThe installation guide and a new FAQ entry cover the \u0026quot;Error writing to storage device\u0026quot; failure when flashing with Raspberry Pi Imager 2.0.2 through at least 2.0.7 on macOS. Update Raspberry Pi Imager past 2.0.7, or decompress the image with \u003ccode\u003ezstd -d\u003c/code\u003e and flash the \u003ccode\u003e.img\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe balena fleet guide uses \u003ccode\u003ebalena env set\u003c/code\u003e instead of \u003ccode\u003ebalena env add\u003c/code\u003e for the host configuration commands.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"for-contributors\"\u003eFor contributors\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003ebalena-host-config.json\u003c/code\u003e declares the \u003ccode\u003econfig.txt\u003c/code\u003e settings for each official balena fleet, and \u003ccode\u003edocs/balena-fleet-host-config.md\u003c/code\u003e explains each one. On every release, the \u0026quot;Build Balena Disk Images\u0026quot; workflow sets them on the fleets and removes any other host configuration variable there, including legacy \u003ccode\u003eRESIN_HOST_CONFIG_*\u003c/code\u003e ones. Fleets you run yourself aren\u0026#39;t touched.\u003c/li\u003e\n\u003cli\u003eA new \u0026quot;Deploy to Balena (manual)\u0026quot; workflow redeploys an existing release to one fleet or all 5 without rebuilding disk images. It and the release workflow share \u003ccode\u003ebin/balena_ota_deploy.sh\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eviewer\u003c/code\u003e user has a fixed UID and GID of 1000 and exists in both the server and viewer images, so it resolves to the same owner in every container that shares \u003ccode\u003e/data\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003euv.lock\u003c/code\u003e was regenerated to match the dev dependency pins in \u003ccode\u003epyproject.toml\u003c/code\u003e, which the \u003ccode\u003euv sync --frozen\u003c/code\u003e step in the image builds checks.\u003c/li\u003e\n\u003c/ul\u003e\n","description":"The balena Releases page shows the real Anthias version, the official Raspberry Pi 5 balena fleet gets the memory setting 4K HEVC playback needs, and the docs cover the Raspberry Pi Imager write error on macOS.","title":"Raspberry Pi 5 no longer fills its storage with core dumps, and other fixes","type":"roundup","url":"https://www.screenly.io/releases/anthias/2026.05.2/fixes-and-improvements/"}],"json":"https://www.screenly.io/releases/anthias/2026.05.2/v1.json","product":"anthias","product_label":"Anthias","url":"https://www.screenly.io/releases/anthias/2026.05.2/","version":"2026.05.2"}],"title":"Anthias 2026.05.2","url":"https://www.screenly.io/releases/anthias/2026.05.2/","version":1}