FieldStation42: Broadcast TV simulation on Linux and Raspberry Pi

FieldStation42's scheduled broadcast and cable model

FieldStation42 is intended for people who want a computer or Raspberry Pi to behave like an old broadcast or cable television system. Its central problem is scheduling. Instead of choosing one program and leaving it running, the project can maintain a daily lineup and move through shows, commercials, station bumps, guide channels, radio streams, and other channel content according to a schedule. The README lists daily lineups, prime time blocks, marathons, and seasonal programming as supported schedule structures.

The target audience is fairly distinct. It suits a maker building a themed television installation, a developer experimenting with channel switching and program automation, or a household that wants a dedicated retro-TV display. It is not positioned as a replacement for a video-on-demand application or a conventional live-TV service. The simulator adds presentation and control layers around locally arranged media, including channel banners and now-playing information.

The project supports several kinds of channels. Its documented channel types include network television, movie channels, guide channels, radio stations, IPTV streams, and looping displays. That range allows a lineup to contain both scheduled program blocks and continuously operating streams. It also means installation depends on preparing each channel's source correctly. The README does not provide a complete channel configuration example, so `confs/` and the full documentation at fieldstation42.com are the relevant places to verify specific settings before committing to a large installation.

Python, MPV, and the FieldStation42 process layout

FieldStation42 uses Python as its primary language and MPV as the playback requirement. The quick start launches the application through `station_42.py`, while the repository also contains `field_player.py` and an `fs42/` package. Based on that layout, the station application is accompanied by dedicated playback and supporting modules. The Makefile shows that the application can be launched either directly with Python or through Docker Compose.

The documented operating environments are Linux systems, including Raspberry Pi OS Bookworm, Ubuntu, Mint, and Debian, plus Windows through WSL. Python 3.10 or newer is required. MPV is also required because it is the stated media playback dependency. Raspberry Pi OS Bookworm is recommended by the README, giving the project a preferred hardware and operating-system target rather than claiming identical behavior across every listed platform.

The Docker path passes display, runtime, and audio-related values into containers. Under the Makefile's `wsl` mode, it forwards `DISPLAY`, uses `/tmp` as `XDG_RUNTIME_DIR`, and points `PULSE_SOCKET` at `/mnt/wslg/PulseServer`. In Linux mode, its defaults instead use `:0`, `/run/user/$(shell id -u)`, and a PulseAudio socket under the current user's runtime directory. It also exposes locations for the catalog, runtime data, and configuration through `CATALOG_LOCATION`, `RUNTIME_LOCATION`, and `CONFS_LOCATION`.

This arrangement is understandable for a media application tied to a physical screen. It also creates a deployment constraint. Playback may depend on the host or container reaching the correct graphical session and audio socket. The README does not document headless operation, hardware transcoding configuration, or recovery behavior when those display and audio endpoints are unavailable.

Installing FieldStation42 and opening the web console

The README gives a direct Linux quick start. The first command installs MPV, Python, pip, and the Python virtual-environment package through the system package manager. On a Raspberry Pi or supported Linux distribution, run:

sudo apt-get install mpv python3 python3-pip python3-venv

This command establishes the documented system dependencies. It requires an administrator account because it uses `sudo`, and package availability can vary outside the Linux distributions named in the project documentation.

Next, clone the repository and enter its directory:

git clone https://github.com/shane-mason/FieldStation42
cd FieldStation42

The installer creates the local environment used by the quick start:

bash install.sh

After the installer finishes, activate that environment and start the station process:

source env/bin/activate
python3 station_42.py

The README then directs the user to open `http://localhost:4242`. A successful start should make the web console available on that local address. The console is where the first channel is configured, according to the quick start. No `curl` request, API payload, or complete channel configuration file is included in the README, so those details should not be inferred.

The sequence assumes Git, `sudo`, and access to the GitHub repository. It also assumes that the installer creates the documented `env/` path. If another Python environment is already active, the exact activation behavior should be checked in `install.sh` before use.

FieldStation42 browser, remote, and HTTP controls

FieldStation42 exposes three documented control paths. The web console is the primary configuration surface for stations. The README describes a web remote that can change channels and control playback from a phone or another device on the network. It also advertises an extensive REST API for playback control, channel changes, status queries, and custom integrations. These interfaces address different jobs. The console configures the system, the remote handles viewer interaction, and the API connects software under an engineer's control.

The REST interface is relevant if the installation needs custom scheduling logic, external status displays, or an integration with another local service. The README does not enumerate endpoints, authentication behavior, request schemas, or response formats. An engineer therefore cannot safely infer a concrete API call from the README alone. The full HTTP contract must be checked in the external documentation or the route implementation before writing an integration.

The web remote depends on network reachability, while the API may also need suitable network exposure. The README does not document a default bind address, TLS configuration, authentication requirement, or reverse-proxy instructions. It therefore does not establish that the API is suitable for exposure outside a trusted local network. The local console is documented at `http://localhost:4242`, but that address does not say whether remote access is enabled by default or secured automatically.

For infrared control, the project supports IR remotes used with a Flirc USB receiver. The on-screen display adds channel banners and now-playing information. These features support a television-style installation rather than a bare command-line player, but they also introduce dependencies on peripherals, display routing, and network configuration.

Docker targets in FieldStation42's Makefile

The repository includes `docker/`, a `docker-compose.yml`, Docker ignore files, and Makefile targets for building and starting the stack. This provides an alternative to activating `env/` and invoking `python3 station_42.py` directly. The visible Makefile targets include `docker-build`, `docker-up`, and `docker-down`. They use Docker Compose with `docker/docker-compose.yml`.

The Makefile selects behavior through variables rather than one hard-coded platform setup. `RUN_MODE` defaults to `local`, while `OS_ENV` defaults to `wsl`. Setting `RUN_MODE=docker` changes the `station_42` target from a direct Python invocation to a Compose lifecycle followed by execution inside a container named `fieldstation42`. The repository also contains a `field_player` target, although its complete definition is not shown in the repository excerpt.

The catalog and runtime locations default to directories outside the repository:

CATALOG_LOCATION ?= ../catalog
RUNTIME_LOCATION ?= ../runtime
CONFS_LOCATION ?= ../confs

These are Make variable defaults, not commands from the README. They indicate that a deployment can separate media catalogs, generated runtime information, and station configuration from the source tree. That separation can help with persistent installations, but operators need to account for host directory mounting and file ownership. The Makefile excerpt does not show the complete Compose service definition, so exact volume declarations and image behavior should be checked in `docker/docker-compose.yml`.

Maintenance, releases, and MPL-2.0 considerations

The repository is not archived, and its last push was on 2026-10-16. There are no GitHub releases, so the repository does not provide a release-based upgrade history or a documented distribution channel such as versioned GitHub releases. The README points to `fieldstation42.com` for the installation guide and configuration walkthroughs. Maintenance status should therefore be judged from repository activity and the documentation, not from a release cadence that does not exist in the repository record.

The project is licensed under MPL-2.0. Anyone redistributing or modifying covered code should preserve applicable license notices and review the repository's `LICENSE` file and actual file boundaries. This is a licensing consideration rather than legal advice. The README says that contributors should open an issue before submitting large changes, which documents a route for discussing substantial work but does not establish acceptance or delivery time.

Upgrade cost is likely to involve checking changes to `install.sh`, `fs42/`, configuration examples, Docker settings, and the external documentation. The absence of GitHub releases means operators cannot rely on a stated semantic-version migration path from the repository record. A deployment should also account for media references in `confs/`, catalog and runtime directories, and any customized display or audio settings.

FieldStation42 versus a conventional media player

A conventional media player generally centers on opening a selected file or stream and controlling that one item. FieldStation42 instead models a television system with schedules, channels, transitions, interstitials, guide content, and remote channel changes. The difference is operational, not merely cosmetic. The user defines channel relationships and timed programming, then the application presents the resulting lineup.

A media server or playlist application is an alternative when the requirement is only to sequence files across a display. Such a simpler tool may reduce configuration work if the installation does not need simulated commercials, station bumps, a cable-box-style interface, or a REST API. FieldStation42 adds value when those television behaviors are part of the goal.

It is also the wrong tool for a user who expects live cable service aggregation. IPTV streams are supported as a channel type, but the README does not claim that FieldStation42 includes a cable subscription service, tuner stack, channel lineup database, or rights management system. Media sources still need to be available to the environment. The project is best understood as a presentation and automation layer for content an operator already has access to.

Editorial conclusion

FieldStation42 fits retro-TV installations, channel lineups, and local media experiments that need a persistent station schedule rather than a conventional media player. It is a poor fit for users seeking a packaged streaming service, supported mobile platforms, or a zero-configuration setup. Before adoption, verify MPV playback on the target display and audio device, confirm that required media paths are accessible, and review the channel configuration workflow at fieldstation42.com.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. README
4. shane-mason/FieldStation42 on GitHub