Anthias 2026.07.1 | Screenly

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.