We got behind on these. The last Anthias post covered v2026.07.1, back in July. Rather than write eight separate posts, this one rolls them up in two parts. v2026.10.0, released on 16 October, is first. What you missed since July is everything between that post and this one.

v2026.10.0

There is nothing new to click. These are fixes for problems that were showing up on real devices, and a few of them were painful.

Background jobs keep running on a low-memory Pi

On a board that was already short on memory, Anthias could take down the jobs that resize images, fetch video, and do the rest of the background work.

Those jobs have a time limit, so a stuck one can be stopped. The signal for that limit was easy to misdeliver. It could arrive after the job had already finished, and hit a worker that was just sitting idle. The idle worker treated it as fatal and quit. From the outside the player looked unstable for no clear reason: work dying, and the worker process quitting.

That was the biggest issue we were seeing. In v2026.10.0 the worker only accepts that signal while a job is actually running, and only once that job has genuinely run too long.

Backups restore without corrupting the database

Two bugs were piling on each other.

The first was quiet until it was not. Putting the database into its write mode on every connection could fail, and each failure leaked a file handle. On one player that climbed, in a single afternoon, from “database is locked” to the device being unable to open its database at all.

The second was in the backup itself. Anthias saved the database while recent writes were still sitting in a side file, and a restore could attach the wrong side file. The database then came up corrupt.

Backups are a clean copy now, and a restore throws leftover side files away before it starts. If you have been nervous about taking a backup, this is the release to move to.

The screen comes up on a slow first boot or after a restore

The screen used to start the moment the server process answered. That is earlier than it sounds. On a slow first boot, or straight after a restore, the database tables were not there yet. The viewer asked for a playlist anyway, failed, and the container restarted into the same loop.

It waits for the database to be ready now.

A failed asset tells you what went wrong

When a media job ran long, Anthias used to kill the worker outright. The asset stayed on Processing, and the page had nothing else to say.

Those jobs stop themselves now and leave a reason on the asset.

A few other dead ends are treated as ordinary failures too, which is what they always were: an image over the size limit, a YouTube link the site refuses, a file deleted while Anthias was still working on it. One of those cases was worse than noise. A device whose hardware name came through as junk text was also silencing the storage check on that player. That check runs again.

Players on the same playlist stay in sync

The pause between assets was added after each one finished playing. Small differences added up, and over a few hours two players on the same list could be seconds apart.

The pause is counted from the start of each turn now, so they stay lined up.

Thank you to DiasonD. This was their first contribution to Anthias.

A 512 MB Pi 3 A+ still needs a lighter playlist

That board still cannot hold a playlist that mixes all four asset types. It wedges on a web page or a stream, and it only holds with a single image.

We confirmed this again before tagging the release. The board was already deep in swap while idle on the previous version, so this is a memory ceiling we have not cleared, and also not a new regression. Pi 2, 64-bit Pi 3, Pi 4, Pi 5, and x86 all ran clean through the same test.

What you missed since July

These shipped after the July post and before v2026.10.0: v2026.07.2, v2026.07.3, v2026.07.4, v2026.08.0, v2026.08.1, v2026.08.2, and v2026.09.0.

v2026.07.2: Pi 2 and Pi 3 show a picture again

In v2026.07.2 the viewer on 32-bit Pi 2 and Pi 3 could crash in a loop and leave a black screen. The cause was in how the browser engine had been built. We rebuilt it and checked the result on real hardware. The picture stays up, and a pair of related crashes on those same boards went away with it.

That release also lets you bring a library across from Yodeck, ScreenCloud, piSignage, or Xibo. Playlists and assets come over together, so you do not have to download everything to a laptop first.

A few smaller additions in the same release are easy to miss, and worth knowing about:

• You can allow a self-signed certificate for a page or a video, including for a single asset.
• A web asset can send custom HTTP headers.
• You can set the device timezone, and Settings shows a clock.
• “No cache” and “Skip asset check” can be edited on many assets at once.
• The 64-bit Pi 3 image plays video in hardware at 30 fps, with audio, and a video that loops in its slot does so with a smaller gap.

On a board with about 1 GB of memory, the browser uses a low-memory mode and the viewer stops holding its output in memory. An upgrade also no longer fails while swap is being turned off.

v2026.07.3 and v2026.07.4: rotation looks the same on every board

v2026.07.3 made screen rotation agree with itself. Pick 90 degrees and you get 90 degrees on a Pi 2 and on a Pi 5, for images, web pages, and video. On Pi 1, Pi 2, and Pi 3, images and web pages had not been rotating at all. App settings that ask for a date or a time now use a real picker. The Pi 2 boot splash no longer falls back to plain text. Container images are signed, and a list of what is inside them is generated with the build.

v2026.07.4 followed up with upside-down video on Pi 1, Pi 2, and Pi 3, sent audio to an output that is actually connected on PCs and 64-bit devices, and fixed previews for images that live on another server.

v2026.08.0: phone photos, big images, and office networks just work

v2026.08.0 is a grab bag of things that used to need a workaround.

A photo from a phone shows the right way up, both when it is uploaded and when the viewer draws it directly. A very large image is scaled down to what the board can hold before it is encoded, so a Pi 2 or Pi 3 is not rebooted by the upload.

A board that boots with no screen attached retries a limited number of times instead of sitting on a blank display. Installs and day-to-day traffic follow an HTTP proxy. A PC resolves names on the first boot after install. Installing from a keyboard and monitor no longer kicks you out of the terminal you are using. A websocket left open and idle no longer hits a timeout.

v2026.08.1: you can schedule the TV, not just the playlist

v2026.08.1 rebuilt HDMI-CEC. It finds the right port when a board has more than one display connection, passthrough works again, and you can turn the attached screen on and off on a timetable.

Oversized JPEG and PNG uploads are scaled down while they are processed on the 1 GB and 512 MB boards, so a multi-megapixel photo does not exhaust their memory. The Menu Board app installs with its menu filled in. It used to come up empty. If the display disappears, the viewer fails quickly instead of staying in a half-working state. Usage reports now include the release version.

v2026.08.2: a warning when the power supply or the SD card is failing

v2026.08.2 adds two warnings to the web interface.

One appears when the power supply cannot hold its voltage. The other appears when the storage card starts developing bad blocks. Both tell you what to do about it, and both stay readable on every screen and in dark mode.

The same release tidied the interface. Labels in the asset editor no longer sit on the hint text. Turning certificate checks off shows a clear “Not secure” badge, so that choice is obvious. The disk and memory charts use one color for one thing.

v2026.09.0: drop a file on the schedule, and see why an upload failed

Drop a file anywhere on the schedule page. Large uploads go out in pieces, so they get through a proxy that rejects one huge request. Uploads, and files already on the device, are sent through as a stream instead of being loaded into memory first. If an upload fails, the page tells you why.

There is one change to read twice if you have anything of your own talking to Anthias. When login is turned on, the live update connection (/ws) now requires a logged-in session. A script that was connecting without one will stop. That is the change in this whole stretch most likely to surprise you.

Quieter fixes from the same release: a backup only includes the files Anthias needs to restore, and it checks the version before it will restore. Running out of memory takes down the right process, and the watchdog aims at a reset that actually happens. An upgrade deletes container images it has replaced. A board that is not a Raspberry Pi is labeled with its real name, instead of “Generic aarch64 Device”. The black screen after a video is shorter. Django is updated to 5.2.17.

Thank you to mickzijdel and Glassto for their first contributions, on the upload error message and that black flash.

Upgrading

Existing installations pick this up on their own. On Balena, the update stays in the container, so playlists and settings carry over.

Docs are at anthias.screenly.io. Every release note is on GitHub.

Thanks to everyone who filed an issue or tried a build between releases. That is where most of v2026.10.0 came from.

Happy displaying.