Digital Signage Software: A Complete Feature Guide (2026)

Most signage feature lists are written to be scanned rather than read: twelve icons, twelve short phrases, and no indication of which four you will actually touch on a Tuesday morning. This guide is the opposite. It walks through each capability in a modern signage platform and answers two questions about it — what is this for, and when should you reach for it.

It assumes you have already chosen a platform. If you have not, the buyer's guide covers pricing traps and shortlisting. Read this one in order the first time, then treat it as a reference.

The five layers, and why the order matters

Almost every cloud signage platform is built from the same five layers, and nearly every "how do I do X" question resolves to "you are working at the wrong layer".

1. Media. The files. Images, video, audio, and references to live sources.
2. Playlists. An ordered sequence of media, with a duration on each item.
3. Layouts. How a screen is divided — one full-bleed region, or up to twelve zones each running its own playlist.
4. Schedules. The rules deciding which playlist or layout is live at a given day and time.
5. Screens and groups. The physical endpoints, and the sets you address collectively.

The dependency runs upward, so when something is wrong on a wall, diagnose downward. Is the screen online? Is a schedule live right now? Does it point at the layout you think it does? Most faults are answered before you reach the media.

The media library and asset hygiene

The media library is the least glamorous part of a signage platform, and the part that decides whether the deployment is still manageable in year two. Estates fail here first: four hundred files called final_v3.jpg, and nobody willing to delete one in case it is on a screen.

A naming convention, decided once

Agree a convention before you upload the second file, not the two hundredth. The one that survives has three parts: scope, subject, date. camden-lunch-board-2026-03 tells you where it belongs, what it is and whether it is stale, from a list, without opening it. Promo final FINAL.png tells you nothing and will still be on a screen in eighteen months. Nest folders by whatever changes least — location for a restaurant group, department for a campus, campaign for retail.

Formats, resolution and what fills your storage

Two rules cover most of it. Export at the resolution the screen will paint, not higher — a 4K image on a 1080p panel carries four times the pixels for no extra detail on the wall. Prefer H.264 or H.265 MP4 for video, because that is what player hardware decodes without touching the CPU.

The free tier includes 200 MB of storage, which is generous for images and tight for video: one well-compressed minute of 1080p can eat a quarter of it. Video-led content is a paid-plan deployment and always was.

Playlists: the unit you actually schedule

A playlist is an ordered list of media, each item with a dwell time. That is all it is; the interesting decisions are structural.

Loop length should match the dwell time of the audience in front of it. A queue that clears in ninety seconds wants a loop shorter than that, so a customer sees the whole message set once. A shop window, whose audience walks past in three seconds, wants very short loops of very simple frames — each has to work alone, because nobody is watching the second one.

Why one playlist per screen is a trap

The instinct at screen three is to build "Screen 3 playlist". It works. At screen fifteen it means fifteen edits to change one price, and one will be missed — reliably, and usually the one customers see most.

Build playlists around content roles instead: a brand loop, a promotions loop, a menu, a local-notices loop. Compose them per screen through layouts and schedules. If changing one message means editing more than one playlist, the structure is wrong; fix it while it is a fifteen-minute job.

Scheduling and dayparting

Scheduling is what separates a screen from a poster. A poster shows one thing; a screen can show the right thing. Dayparting is scheduling by time of day and day of week — the breakfast board that becomes the lunch board at 11am on weekdays and at noon on Sundays.

Designing dayparts

Start from the operation, not the screen. Write down the parts of the day in which what you sell, say or need people to know is genuinely different; most businesses find three or four. If you cannot articulate why two adjacent parts differ, merge them — every extra daypart is another piece of content somebody has to keep current, and unmaintained content is worse than none.

Handle the edges deliberately. The switch should land slightly before the operational change, because a customer deciding at 10:58 is deciding on lunch. And decide what plays outside all defined dayparts: a fallback playlist is right for most sites, since a blank screen reads as broken.

Overlaps and the failure nobody sees

Ask any platform, including this one, what happens when two schedules claim the same screen at the same moment. Silent last-write-wins produces the worst failure in signage — the wrong content, nobody able to explain why, no error anywhere. Qmanja Signage checks for the clash at the point you create it rather than resolving it invisibly at playback. Keep the rules coarse: three schedules per group that anyone can reason about beats eleven only their author understands, and their author leaves eventually.

[SCREENSHOT: scheduling view showing a day-and-time rule and a detected overlap]

Content schedules and power schedules are different

A content schedule decides what plays while the screen is on. A power schedule decides whether the screen is on at all. You want both, and people routinely configure only the first. A screen that sleeps at closing and wakes before opening saves whatever the gap between your trading hours and twenty-four is — work it out from your own opening times — in electricity, and more importantly in panel life.

Layouts and split-screen zones

A layout divides one display into independent regions, each running its own playlist, live stream or widget. It has the most direct hardware consequence of any feature: three zones on one panel is one panel, one mount and one player instead of three.

How many zones is too many

Qmanja Signage supports up to twelve zones per screen. Twelve is a capability, not a recommendation:

• One zone for anything with a walking audience — windows, entrances, corridors. Split content at three metres and nobody reads any of it.
• Two or three zones for the large majority of real deployments: main content, a secondary panel, a ticker or clock strip.
• Four to six zones for dashboards, arrivals boards and internal comms screens, where the audience is stationary and actively reading.
• More than six almost always means the screen is doing two jobs and should be two screens.

The constraint nobody plans for is decoding: every video zone is another simultaneous decode. Cheap sticks manage one comfortably, a powered box two or three, and a Windows mini-PC is the honest answer for heavy multi-zone work. The players page sets out which device suits which load.

Proportional layouts, and why it matters later

Ask how layouts are stored. Zones defined in fixed pixels have to be rebuilt for every resolution and orientation you own. Zones defined as percentages fit everything — the same layout works on a 1080p landscape panel and a 4K portrait one. Qmanja stores zones as percentages, which is what makes rotation to 90, 180 or 270 degrees a screen setting rather than a redesign. Save the layouts that work as templates; the value appears at the tenth screen.

Synced video walls

A video wall is a grid of panels behaving as one canvas. Software syncing — rather than a hardware controller — means each panel has its own player, and the platform keeps their playback aligned with each rendering its own slice of the image. Qmanja supports grids up to six by six.

Three things decide whether a wall looks right. Identical hardware, because mixed panel models drift in colour and in wake time, and both are obvious across a seam. Wired networking to every player, because sync tolerance is far tighter than ordinary playback and Wi-Fi jitter shows as a visible tear on fast motion. Content built for the wall's aspect ratio, not a 16:9 asset stretched over a 3x3 with bezels eating the middle of every face. Test with real motion before signing off; a static image looks perfect on anything.

Live streams and web sources

Static content goes stale, and content that goes stale stops being looked at. Live sources are the antidote, in two groups.

Live video — YouTube, Twitch, an HLS feed from your own encoder. Useful for events, all-hands, a sports feed in a bar, or anywhere a camera is genuinely showing something. Qmanja plays streams straight from the source rather than proxying them. Where a platform routes streams through its own infrastructure instead, ask how that traffic is billed — on a screen streaming all day it is a line worth understanding before you sign.

Web sources — any URL. This is the underrated one. It is how a BI dashboard, a room-booking board or a slide deck reaches a screen with nobody exporting anything. The shift is from "somebody must remember to update this" to "this updates itself", and that is the difference between a screen that is current in month six and one still showing a Christmas promotion in March.

Two cautions. A web source behind a login will display a login page on your wall, so use a public or token-based URL. And a dashboard designed for a laptop is unreadable at four metres — build a display-specific view with fewer numbers and larger type. The feature overview covers what else fits in a zone alongside one.

Offline caching

Media is cached on the device, so a screen keeps playing its last published schedule through a network outage and reconciles automatically when the connection returns. What you lose offline is publishing changes, live status and live streaming sources.

The consequence people miss is that good offline behaviour hides failure. A screen offline for a week looks perfectly healthy from the shop floor; it is simply playing a week-old schedule beautifully. That is why offline alerting exists — an email when a screen has not checked in for longer than your threshold. A few hours suits reliable wired networking; a full day is more sensible where connectivity is genuinely intermittent.

Proof-of-play reporting, and what it is actually for

Proof-of-play logs record what appeared on which screen and when. It is the feature most often bought for one reason and used for another.

The three jobs it really does

• Compliance evidence. Where a message is required rather than optional — a safety notice, an allergen board, a regulatory disclosure — the log records that it ran, on which screens, for how long. It cannot be reconstructed after the fact, so it has to be on before you need it.
• Advertiser and stakeholder reporting. If you sell screen time, or run screens for a landlord, a franchisee or a department, the log is the delivery report. It turns "your ad ran" into a line-by-line count you can attach to an invoice.
• Spotting dead screens. The most common use in practice, and the one nobody buys it for. A screen playing the wrong loop, or the same loop forever because a schedule expired, raises no alert — it is online and playing. Uptime tells you a screen is reachable; proof-of-play tells you it is correct, and only the second is what customers see.

What it does not tell you

Proof-of-play measures delivery, not effect — it cannot tell you whether anyone looked. To find that out, design the measurement separately: hold everything else constant, change one variable, compare matched periods or sites, and pick a metric the screen can plausibly move, such as attachment rate rather than total revenue. Proof-of-play is what makes that comparison trustworthy.

Logging is opt-in per screen, the right default. Log the screens carrying compliance content or sold inventory, leave it off for the office lobby, and export to CSV.

Multi-user access and per-site roles

Irrelevant at one screen. Decisive at twenty, and the reason multi-site deployments quietly fail.

Every chain hits the same governance question: how do you let a local manager publish local content without letting them edit head office's template or another site's screens? The answer is roles scoped to outlets — editors confined to the locations they run, viewers who can see but not change, and a small central team with estate-wide rights.

Getting the balance right

Both failure modes are terminal. Too restrictive and one person becomes the bottleneck for forty sites, content goes stale and within a quarter nobody looks at the screens. Too permissive and the screens fill with unapproved clutter. The workable middle is structural rather than procedural: a locked central zone local users cannot touch, and a local zone they own outright, in the same layout. Nobody needs an approval queue, because the layout enforces the boundary. Restaurant groups and retail chains land on exactly this shape; campuses arrive at the departmental version. An audit trail — who changed what, when — is what makes delegation safe enough to use.

[SCREENSHOT: team management view showing a user scoped to a single outlet]

Pairing: how a screen joins your account

Pairing exists so nobody types an account password into a TV remote — a credential entered on a device in a public space is a credential you have effectively published.

The flow is the same on every platform. The player displays a six-character code. You enter that code in the dashboard on a phone or laptop, and the screen claims itself to your account within seconds and starts playing whatever is scheduled for it.

[SCREENSHOT: player showing the six-character pairing code on a display]

Do two things while you are there, because retrofitting them across an estate is tedious. Name the screen something you will recognise in a list of forty — "Camden, menu board left", not "Screen 12" — and assign it to its outlet and groups immediately, so it inherits schedules rather than needing its own.

Platforms: what runs where today

Availability is the one section of a feature guide that must be read literally, so here it is without hedging. Nothing still in development belongs in a plan with a delivery date attached.

Live today

Any web browser. Nothing to install. Open the web player in Chrome, Edge, Firefox or Safari, pair it, and it behaves like any other screen in the account. It is the fastest way to see the platform working, and the practical answer for any machine without a dedicated app — a Mac, a Linux box, a Chromebook, a single-board computer. That is a statement about the browser player, not a claim of a native app for those devices.

Android TV. The default for most estates, because the device costs less than the bracket it hangs behind. Install from the Play Store, pair with the code, then spend ten minutes on the settings that actually matter: sleep, screensaver, ambient mode and auto-start on boot. Those settings, not the software, cause the great majority of blank-screen reports — the Android TV setup guide covers each one.

Amazon Fire TV. The cheapest route to a live screen, and fine for single-zone playlists in a ventilated position. Its limits are physical rather than software: sticks throttle in enclosed mounts, and multi-zone or sustained 4K asks more than the hardware gives. The Fire TV guide is honest about where that line falls.

Windows. A single self-contained installer, no runtime or framework first, on Windows 10 and 11. The right player for heavy multi-zone layouts, demanding 4K and screens already driven by a PC. On a kiosk, lock the machine to the player and log it in automatically; Microsoft's assigned access documentation is the reference.

In development, and in review

macOS is in development — a native build for Intel and Apple Silicon. Until it ships, run the web player in Safari or Chrome. iOS and iPadOS is in App Store review, aimed at countertop and tablet displays. Samsung Tizen and LG webOS are both in development. Those two are system-on-chip: the player runs inside the panel, so there is no external box and one less thing to fail. If you are specifying panels now, the Tizen guide and the webOS guide explain how SoC signage works and what to check on the quote — and meanwhile those panels drive perfectly well from an external Android TV or Windows player.

Deployment practice at 1, 10 and 100 screens

The same platform gets used three different ways depending on scale. The mistake is running a hundred screens with the habits of one.

One screen

Optimise for finishing. Use the free tier — one screen, 200 MB, no card — and get real content on a real display in a single sitting rather than designing a system. One playlist, no layout, no schedule beyond an operating-hours power rule. Then run the two tests that predict everything later: leave it going overnight and look at it in the morning, and pull the power at the wall and time how long until content returns with nobody touching a remote.

Ten screens

This is where structure starts paying, and where most estates accidentally build the mess they live with for years.

• Groups before screens. Define the groups and create them at pairing time. Building the structure afterwards across ten screens is an afternoon you do not get back; across forty it is a project.
• Playlists by role, not by screen. If one price change means more than one edit, stop and restructure.
• Stage on a bench. Power up every device in one room, update, install, configure and pair before anything goes up a ladder. Devices that are going to fail usually fail in the first hour.
• One configured spare per site. A pre-paired device in a drawer turns a hardware failure from a ticket into a two-minute swap.
• Label physically and digitally with the same name. When somebody says "the one by the door is stuck", you want to find it in a list without walking the building.

A hundred screens

At this scale the platform is no longer the hard part. Governance and content supply are.

Decide who publishes what before you deploy. Roles scoped to outlets, a locked central zone, a local zone local staff own. Retrofitting a permissions model onto a live estate means either breaking people's access or leaving it open.

Standardise hardware ruthlessly. One player model per role, bought in one batch. Every variant is another set of device settings to explain to whoever inherits this.

Name the person responsible for content. Deployments this size fail on content supply far more often than on technology, and a hundred screens showing last quarter's campaign is a worse outcome than ninety showing this quarter's.

Instrument it. Offline alerts with a sensible threshold, proof-of-play on the screens carrying compliance or sold inventory, and someone who reads both — you cannot see an estate this size by walking it. Above twenty screens you are into Business pricing, which is quoted rather than listed; worth a conversation at the planning stage rather than after the purchase orders.

Where to start

Three things are worth taking from this guide: build against groups from the first screen, structure playlists by content role rather than by screen, and switch the reporting on before you need it. All three cost nothing at one screen and are expensive to retrofit at fifty.

Everything else here is a capability waiting for a problem, so wait for the problem.