240-MP: A Retro VCR Frontend for Raspberry Pi, SteamOS and macOS ARM

What 240-MP Is For, and Who It Is Not For

240-MP is a frontend, not a media server and not a general-purpose player. It presents a VCR-styled interface, and the README says it is designed first for CRT displays, running on a Raspberry Pi, SteamOS (or another Linux x86_64 distribution), or macOS on ARM. Playback itself is delegated to MPV, which the README states is installed or updated as a dependency during the install steps.

The target user is someone building a single-purpose machine: a Pi wired to an old television, a Steam Deck or small Linux box on a shelf, a Mac mini driving a display across the room. The interface assumes you are operating it from a distance with a remote or gamepad rather than a keyboard and mouse, and the whole visual language leans on that.

If you want a desktop media player you open alongside a browser, this is the wrong shape. It is also wrong if you expect it to index and transcode your library itself. It has no server component. Every library it browses comes from Plex, Jellyfin, Emby or a folder on disk, and every file it plays is handed to MPV. Your codec support is MPV's codec support, which is the single most important thing to understand before installing.

Modules as VHS Deck Inputs

The README describes playback experiences as modules, and asks you to think of each module as a different input on a VHS deck. That analogy is doing real work: modules are selected from a menu, and each one brings its own browsing model and its own authentication.

Eight modules ship with the project. Local Files browses folders and supports m3u and m3u8 playlists, loop, shuffle and playback history. Plex, Jellyfin and Emby each connect to a server with their own auth flows: Plex has server switching and user profile switching with auto sign in, Jellyfin uses Quick Connect, and Emby supports username and password or Emby Connect with a server picker. YouTube and NFC Reader have additional dependencies documented on their wiki pages under "To Enable" sections. Weather pulls forecasts from Open-Meteo worldwide and current conditions from NWS for US locations, and is explicitly inspired by WeatherStar 3000+ by netbymatt. Ambient:Mode loops video or audio as a background, in the spirit of art modes on modern televisions.

The shared media modules converge on a similar feature set: Continue Watching, Next Up, resume, optional autoplay of the next episode in a season (off by default), collections, browsing by letter, show and season browsing, and a choice between Direct Playback and Transcode. That last choice matters more than it looks. Direct Playback is the default, and if your server or network cannot sustain the file, the fallback is a transcode, which costs server CPU.

One module deserves separate attention. Scripts lets you run your own .sh files from a folder, with two run modes set in a .txt file beside each script: console keeps 240-MP on screen and shows the script's output; takeover gives the script the whole display and 240-MP returns when it exits. A .txt file is created automatically the first time a script is seen, and you can mark a script as a favorite to put it on the main menu. The README names FieldStation42, RetroArch, yt-dlp -U and updates as examples. This module is off by default and must be enabled in Settings.

Installing 240-MP and Playing a First File

The repository ships an INSTALL.md alongside BUILDING.md and CMakeLists.txt, and the README points to its Install section rather than reproducing steps inline. The README also states that MPV is installed or updated as a dependency during those install steps, so the installer touches software outside the project directory. Read INSTALL.md on the target machine before running anything.

The repository layout separates the QML entry point (Main.qml) from modules/, views/, src/, assets/, packaging/ and scripts/. The scripts directory is where the NFC reader setup script lives, referenced in the README as `scripts/setup-nfc-reader.sh`.

If you want the NFC Reader module with a PC/SC reader, that script is the documented path:

scripts/setup-nfc-reader.sh

The README says PC/SC contactless readers such as the ACS ACR122U need `pcscd`, which is what this script addresses. The PN532 USB reader is recommended instead because it needs no drivers or daemon on any platform, which is why it also works on immutable distributions like SteamOS. Readers are detected automatically, with no configuration.

Card mappings live in an `nfc_tags` data directory, one text file per card, and tapping an unknown card auto-creates a stub tag file for it. That stub behavior is the fastest way to confirm the reader is working: tap a blank card, then look for the new file in `nfc_tags`.

For the Scripts module, enable it in Settings and point it at a folder. Drop a shell script in, and 240-MP creates the companion .txt file on first sight. Set the run mode there, and press play/pause on the script in the list to favorite it onto the main menu.

Where 240-MP Breaks Down

The dependency on MPV cuts both ways. Because 240-MP hands playback to MPV, a file MPV cannot decode will not play, and the README does not describe a fallback player or a codec check before playback starts. The Local Files module lists supported extensions (`mp4`, `mkv`, `avi`, `mov`, `m4v`, `webm`, `wmv`, `flv`, `f4v`, `mpg`, `mpeg`, `vob`), but a container extension says nothing about the codec inside it. An AVI with an unusual video codec is still an AVI.

Transcoding is the escape hatch for server-backed modules, and it is a real cost. Direct Playback is the default for a reason: it pushes the work to the client and the network. Switch to Transcode on a Raspberry Pi and the server takes the load, not the Pi. On a low-power server that trade can be worse than the original problem.

The hardware story is also narrower than the platform list suggests. The README links a Hardware Testing wiki page for Raspberry Pi and says "preferably hooked up to a CRT TV." Getting a Pi to output a signal a CRT accepts is its own project, and the README does not walk through it. SteamOS is called out partly because the PN532 reader avoids a daemon, which tells you the project cares about immutable systems. That is a design decision, not a guarantee that every module works there.

Finally, the NFC Reader's card-to-video mapping depends on files in a data directory. Move that directory or lose it, and your cards point at nothing. Nothing in the README suggests the mappings are exported or backed up.

240-MP Against Kodi and the RetroPie Route

The obvious alternative is Kodi, and the difference is architectural. Kodi is a full media center: it owns the library, the scraper, the player and the add-on ecosystem. 240-MP owns none of that. It is a presentation layer that browses remote libraries and hands files to MPV. If you want Kodi to manage your metadata and playlists locally, 240-MP is not competing with it; it is solving a different problem, which is looking and feeling like a VCR on a CRT.

If your goal is emulation with a side of media, the RetroPie route is the better-known path. The Scripts module in 240-MP explicitly names RetroArch as something it can launch, which is a hint at the intended relationship: 240-MP as the front door, other software behind it. That is a different bet from installing a full retro-gaming distribution and adding a player.

The honest comparison is that 240-MP trades breadth for a specific interface. Kodi will do more, on more hardware, with more documentation. 240-MP will do a narrower set of things in an interface that is the whole point. If the interface is not the point for you, the trade is bad.

Maintenance, Releases and the GPL-3.0 Licence

240-MP is released under GPL-3.0, and the repository carries LICENSE, SECURITY.md and CONTRIBUTING.md at the top level. GPL-3.0 is a copyleft licence: if you distribute a modified version, the source of your modifications has to be available under the same terms. Running it privately on your own Pi does not trigger distribution obligations. If you are a vendor planning to ship a modified 240-MP on hardware, the licence question is worth raising with a lawyer rather than guessing from a README. This is not legal advice.

Maintenance looks current rather than dormant. The last push was on 2026-09-14, and the release history shows v2026.09.14 on 2026-09-14, v2026.09.07 on 2026-09-07 and v2026.08.24 on 2026-08-24. That is a weekly cadence across roughly three weeks, and the version scheme is date-based, which makes it easy to see how far behind you are.

Upgrade cost is the part the README does not document. There is no stated rollback procedure, no migration note for the data directories that modules rely on, and no compatibility matrix between releases. The installer updates MPV as a dependency, so an upgrade can change your playback stack even when 240-MP itself changed little. The Scripts module can run an update script, which suggests the project expects in-place updates, but the README does not describe how to recover if one goes wrong.

Editorial conclusion

Adopt 240-MP if you are building a dedicated playback box whose display is a CRT or a TV across the room, and you want Plex, Jellyfin or Emby libraries plus local files behind one remote-driven interface. Skip it if you need a general-purpose desktop player, or if you want to point it at a media library and have every file play without checking codec support first. Before you commit, verify the one thing the README leaves open: which MPV build the installer puts on your machine, and whether that build handles your files. Read INSTALL.md and the Hardware Testing wiki page for your board, then install on the target machine and play one file from each module you intend to use.

Frequently asked questions

Official sources

1. anthonycaccese/240-MP on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases