Running an Unattended Video Node on Locked-Down or Offline Industrial PCs
The machine on site is rarely the machine you would choose. It is a fanless industrial PC from 2011, running an OEM copy of Windows 7 that must never be updated, sitting behind a wall with no internet and no keyboard. The job is to make a video node that installs once, survives reboots, and answers the network — without touching the operating system.
Why deployment is the hard part, not playback
Playing a video full-screen is solved. The difficulty in exhibition and installation work is that the playback machine is almost never under your control:
- It is old — a 2011-era industrial PC, an embedded panel, a Raspberry Pi handed to you by the client.
- It is frozen — IT will not allow Windows updates, .NET upgrades, or new runtimes on a machine that has worked for years.
- It is offline — no internet, sometimes no DNS, often air-gapped for security.
- It is unattended — bolted behind a wall, powered from the gallery’s main switch, expected to come up on its own every morning for the next three years.
A player that needs a recent OS, a system update, a missing DLL, or a cloud login is the wrong tool for this environment. What the site needs is a node that makes zero assumptions about the host.
Run on hardware you are not allowed to update
DearScenario Player ships as a self-contained build. It does not pull in a system-level runtime, it does not ask for a framework install, and it behaves the same on a 2011 Windows 7 box as it does on Windows 10. There is no “please install the latest Visual C++ / .NET / media pack” step, because the dependencies it needs travel inside the build.
The practical effect: you can hand the portable release package to a machine that IT has frozen, and it runs without a single change to the operating system. No updates, no missing DLL dialog, no codec pack — the playback engine (libmpv) is bundled, so format support does not depend on whatever the host happens to have.
| Host situation | What DearScenario Player needs |
|---|---|
| Windows 7, never updated | Nothing — runs the same as Windows 10 |
| No internet / air-gapped | Nothing — install is fully offline |
| No admin willing to add runtimes | Nothing — dependencies are bundled |
| Unknown codecs on host | Nothing — libmpv is built in |
One behavior, three install methods
The same node runs on Windows and on Raspberry Pi, controlled by the same playback command model over HTTP and OSC. What changes between platforms is only how you put it on the machine — not how it behaves once it is there.
Windows industrial PC → portable ZIP (.zip, offline)
Raspberry Pi (existing) → .deb package (offline-installable)
Raspberry Pi (fresh) → flash a prepared SD imagePick the delivery that matches the hardware in front of you. A controller written against one node works against all of them, because the API surface is identical. This is what lets you quote a project before you know whether the venue will give you a PC or a Pi.
Self-starting and self-recovering
An unattended node has to handle the only interaction it will ever get: the power going off at night and back on in the morning. Two things make that reliable:
- Start on boot. Configure auto-start through the target platform's deployment mechanism—for example, a Windows scheduled task or service wrapper, Pi Lite's systemd service, or the Desktop autostart helper.
- Come back after power loss. Because the node starts with the machine and begins listening immediately, a hard power cut followed by power-on returns the system to a controllable state on its own — no operator, no keyboard, no monitor required.
The goal is a machine that someone can switch off at the wall and switch on the next day, with nobody on site who knows anything about it, and have it answer the network as if nothing happened.
It tells you where it is
The hardest part of a headless box behind a wall is the first five minutes: you need its IP address before your controller can reach it, and there is no screen to read it from. For commissioning, start DearScenario Player with --maintenance: its idle guide shows the network information (IP and listening ports) for a technician to record. Normal mode starts with black idle or a configured background image; it does not show the diagnostic guide.
Record the address, stop the Maintenance process, and restart in Normal mode for the show. Use HTTP status and screenshots to observe production playback. Local and browser engineering panels require a process started with --maintenance.
A realistic deployment checklist
- Install offline. Carry the Windows ZIP, the
.deb, or the SD image on a USB stick. No download step on site. - Enable auto-start using the target platform's deployment mechanism so the node comes up with the machine.
- Commission in Maintenance mode (
--maintenance), read the IP from its idle guide, then restart in Normal mode for production. - Point your controller at the node over HTTP or OSC and verify playback through
GET /api/statusover HTTP. After a restart, send a new playback command or provide an explicit launch target. - Power-cycle the machine from the wall switch and confirm it returns to a controllable state unattended.
- Hide the machine. No keyboard, no monitor, no further access required.
Where DearScenario Player fits
DearScenario Player is a playback API node built for exactly this constraint: hardware you do not control, cannot update, and cannot reach once it is installed. It runs headless on an old Windows PC or a Raspberry Pi, installs offline, starts through the platform’s auto-start mechanism, shows its address during Maintenance commissioning, and waits for control commands — with no cloud account, no subscription, and no dependency on the host’s operating system.
It is free. The constraint it removes is not “which player has the most features,” but “will this still be running, unattended, on a frozen 2011 PC, three years from now.”
Next step: Build an HTTP-controlled playback node to see the API the deployed machine will answer, or download DearScenario Player and try an offline install.

