Anthias 2026.07.2 | Screenly

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.