Screenly 26.8.3 | Screenly

Screenly 26.8.3: Landscape, Portrait, Full HD, UHD and Anywhere are no longer automatic labels

Mon, 17 Aug 2026 00:00:00 +0000

Screenly used to put 5 labels on screens by itself: Landscape, Portrait, Full HD, UHD and Anywhere. Screenly maintained them from each screen’s own properties, which meant you could not rename them, delete them, or decide which screens carried them.

They were not describing screens well enough to earn that. All but one of them stood in for properties a screen already reports, and the two resolution labels were thresholds rather than descriptions: Full HD went on anything from 1920x1080 up to just below 4K, so a 1440p display and a 1080p one carried the same label, and a display below 1080p got neither. Displays that aren’t 16:9 fared worse, because both edges had to clear the bar: a 3840x1600 ultrawide counted as Full HD rather than UHD, and a 1680x1050 display got no resolution label at all.

The groupings were also seldom a useful target. Every portrait screen, or every Anywhere screen, spans different sites, rooms and purposes that have nothing else in common.

So they are ordinary labels now. The ones in your workspace keep the screens they were on, and you can rename, delete or apply them like any label you made yourself.

If a playlist plays on one of these labels: it now plays on the screens that carried the label at this release, and that set no longer updates by itself. A new landscape screen will not join the Landscape label on its own, and a screen you rotate will not change labels. Check any playlist that targets these five, and either maintain the label yourself or assign the screens directly.

If your workspace already had its own label with one of those five names, the two are now a single label holding both sets of screens.

Targeting content by a screen’s own properties, rather than through a label standing in for them, is what we are working on instead.

For developers

The label type field on API v4 and v4.1 changes with this, and filtering by a removed type now returns an error. The API side of this change lists the values that remain and what to update.

Screenly 26.8.3: The label type field on the API now has three values instead of nine

Mon, 17 Aug 2026 00:00:00 +0000

Labels on API v4 and v4.1 carry a type, and that field described how a label was maintained. With Screenly no longer maintaining any label automatically, 6 of its 9 values no longer exist: landscape, portrait, full_hd, uhd, anywhere and virtual. What remains is all-screens, manual and screen.

Labels that reported one of the removed types now report manual, since that is what they have become, and keep their id. The exception is a workspace that already had a label of its own with the same name, such as its own Landscape: the two were merged into that existing label, and the former automatic label’s id no longer exists.

If this affects you: an integration that filters labels by type=landscape, or any of the other five, now gets an error back, because the value is no longer valid for the field. Filter by label name instead, or read the screen’s own resolution and orientation where you were using the label as a proxy for hardware. If you stored the id of an automatic label, look the label up by name again.

Screenly 26.8.3: The App Store and your installed apps are now separate sections

Mon, 17 Aug 2026 00:00:00 +0000

Apps was one page doing two jobs. It opened on the apps you could add, with a My Apps button leading to the ones you had already installed, so anyone coming in to adjust an app already running on their screens started among the ones they did not have.

They are now two sidebar entries. App store is for finding and adding apps, Apps is for the ones you have installed, and each opens where you meant to go.

Both moved address as part of this, so a bookmark straight to the old Apps page needs updating to the section you want.

Screenly 26.8.3: Pages behind a login are no longer turned away before they load

Mon, 17 Aug 2026 00:00:00 +0000

This finishes the work on pages behind a login that Screenly renders on its own servers, which we started earlier this month.

Pages that took more than 2 seconds to respond once signed in were still being turned away before they loaded, so the screens showing them displayed nothing at all. A blank screen is harder to work out than a login page, because there is nothing on it to tell you what went wrong.

Those pages are captured and reach the screen now.

Screenly 26.8.3: Sidebar and sign-in icons show up in Safari

Mon, 17 Aug 2026 00:00:00 +0000

Icons that appeared blank in Safari, in the sidebar and on the sign-in buttons, now show up.