Fred TV (open-tv): a Rust and Tauri IPTV player you build or install from a package

The IPTV client problem Fred TV targets

An IPTV subscription is usually just a URL. The provider hands you an M3U playlist or an Xtream Codes login, and everything after that is your problem: parsing tens of thousands of channel entries, keeping categories and favorites straight, and getting a video pipeline that does not stutter on a 1080p feed. Most people end up in VLC, which plays anything but treats a 40,000-line playlist as a text file. Fred TV exists to be the layer between the provider and mpv: it imports the source, indexes it, and hands a single stream URL to a player that is actually built for video.

The README frames the audience directly. It lists M3U file, M3U link and Xtream as import formats, multi-source support, favorites, custom channels, sharing custom channels with friends, and re-streaming a channel to a phone or TV. The hotkey list, with Backspace and Esc for back and Tab and Shift+Tab for navigation, is written for someone sitting on a couch with a remote, not at a keyboard. That is the intended user: a person with a TV, a remote or air mouse, and an existing subscription.

Rust core, Angular shell, mpv for playback

The repository splits into two halves. src/ holds an Angular 17 application built on Angular Material and ng-bootstrap, and src-tauri/ holds the Rust side, since the app is a Tauri 2 desktop bundle rather than an Electron one. package.json confirms the shape: @tauri-apps/api at ^2.9.0, the clipboard, dialog, notification and shell plugins, and @tauri-apps/cli in devDependencies. The Rust core is where the IPTV work happens, and the Angular layer is the UI that draws channel lists and settings.

Playback is deliberately not in the app. The README states the app depends on mpv, ffmpeg and yt-dlp, and the Windows .msi bundles mpv. That decision explains the performance claims in the README about low RAM usage and instant search: the stream never touches the webview, so the Angular process is not decoding video. It also explains the failure mode. If mpv is missing or too old, the app has nothing to hand the stream to, and yt-dlp being stale breaks any source that resolves through it. ffmpeg sits in the middle for recording and for the re-streaming feature.

The Dockerfile reinforces the split. The builder stage installs libwebkit2gtk-4.1-dev, libgtk-3-dev and librsvg2-dev, pulls Node 22 from NodeSource, installs Rust through rustup, and runs npm run tauri build -- --bundles deb. The runtime stage installs that .deb plus mesa-utils, libgl1-mesa-dri, mpv, ffmpeg and yt-dlp, and sets WEBKIT_DISABLE_DMABUF_RENDERER=1. That last variable is a WebKitGTK rendering workaround, and its presence in the image is a hint that the webview is the fragile part of the stack on Linux.

Installing Fred TV on Windows, Linux and macOS

The README sends you to platform stores first. There are badges for the Microsoft Store, Flathub under dev.fredol.open-tv, the AUR package open-tv-bin, the Apple App Store, and Google Play under dev.fredol.open_tv. For Linux, the README is explicit: install from Releases or Flatpak, and it calls Docker not necessarily the recommended way. If you are on Windows or using the Flatpak, the prerequisites section says to skip dependency installation entirely.

On macOS and on non-Flatpak Linux, you install the three external tools yourself. The README gives one command per distribution, and these are the exact lines it lists:

brew install mpv ffmpeg yt-dlp #MacOS
sudo dnf install mpv ffmpeg yt-dlp #Fedora
sudo zypper install mpv ffmpeg yt-dlp #OpenSUSE
sudo pacman -Syu mpv ffmpeg yt-dlp #Arch
sudo apt install mpv ffmpeg yt-dlp #Debian/Ubuntu

Two notes from the README matter here. On Fedora you must add rpmfusion before those packages are available. On Debian and other LTS distributions, the README strongly suggests a backport for yt-dlp, which is the usual symptom of a distro shipping a version too old for current extractors. The Docker route is documented with two variants, one for Nvidia and one for Intel and AMD:

docker run --rm -it \
  --net=host \
  --env="DISPLAY" \
  --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" \
  --volume="$HOME/.Xauthority:/root/.Xauthority:rw" \
  --volume="$HOME/.local/share/open-tv:/root/.local/share/open-tv" \
  --device /dev/dri \
  ghcr.io/fredolx/open-tv:latest

The Nvidia variant swaps --device /dev/dri for --gpus all. Both mount $HOME/.local/share/open-tv into the container, which is where your imported sources and settings live, so the volume is what makes the container survive a restart. Note the image tag and the config path still carry the old open-tv name even though the app is now Fred TV. For a first run, open the app, import an M3U link or Xtream login, and use Ctrl + f to search once the source has been indexed. Ctrl + q, Ctrl + w and Ctrl + e toggle live streams, movies and series respectively, which is how you cut a large playlist down to the part you actually watch.

Stream caching, recording and the limits the README admits

The README's settings section documents exactly one tunable: Stream Caching. It gives reasons to enable it (a slow connection or provider causing frequent pauses) and reasons to disable it (streams that drop completely, a good connection where you want lower latency, and a note that disabling can prevent some weird bugs and slowdowns). Read that list carefully. The same setting is recommended both for unstable streams and for the bugs it causes, which means there is no default that suits everyone and the README does not tell you which way it ships.

Recording while watching is listed as a feature, but the README does not document where recordings are written, what container they use, or whether recording works on a channel that is being re-streamed at the same time. Re-streaming to a phone or TV is listed without protocol details. Custom channels can be created and shared with friends, but the README does not describe the export format. None of this is fatal for a desktop player, but it means the recording and sharing features are the parts you should test before you depend on them.

The heavier limitation is structural. On Linux outside Flatpak, Fred TV is only as good as the mpv, ffmpeg and yt-dlp your distribution ships. A stale yt-dlp breaks sources that resolve through it, and there is no bundled fallback. The README recommends a backport on Debian LTS, which is an admission that the packaged version is often not enough. The Docker path exists but the README itself calls it not necessarily recommended, and the runtime image sets WEBKIT_DISABLE_DMABUF_RENDERER=1, a workaround rather than a fix.

How Fred TV differs from VLC and from a self-hosted IPTV server

The obvious alternative is VLC. VLC opens an M3U and plays it, and it is already installed on most machines. The difference is in what each program treats as the main object. VLC treats a playlist as a list of media files and gives you a generic media library. Fred TV treats the provider as a source with categories, favorites, movies and series as separate modes, and a remote-friendly keymap. If you watch one channel a week, VLC is less setup. If you have an Xtream login with 20,000 entries and a remote in your hand, the indexing and the Ctrl + q / Ctrl + w / Ctrl + e filters are the point.

The other category is server-side IPTV middleware, which runs headless on a NAS or VPS and serves streams to whatever client connects. Fred TV is the opposite shape: it is a desktop app with a GUI, a WebKitGTK or WebView2 dependency, and a display. There is no documented headless mode, no web UI you can reach from another machine, and the Docker image still needs --net=host, an X11 socket and DISPLAY to run. If your goal is a server that transcodes for several televisions, Fred TV is the wrong tool, and the Docker instructions make that clear rather than hiding it.

Licence, maintenance and what an upgrade costs

Fred TV is GPL-2.0. That matters if you plan to fork it or ship it inside a product: GPL-2.0 carries source distribution obligations for derivative works, and the repository ships a LICENSE file at the top level. Nothing here is legal advice, and the interaction between the GPL-2.0 core and the Angular and Tauri dependencies is something to check with your own counsel if you redistribute. For an end user installing from Flathub or the Microsoft Store, the licence has no practical effect.

The last push to the repository was on 2026-06-14. The most recent release is v1.9.1 from 2026-01-19, described as bug fixes and bulk operations, following v1.9.0 on 2026-01-12, which the release notes describe as all-around improvements and a name change. That name change is visible throughout: the README title is Fred TV (Formerly Open TV), while the package.json name is still open-tv, the AUR package is open-tv-bin, the Flatpak ID is dev.fredol.open-tv, the container image is ghcr.io/fredolx/open-tv, and the config directory is $HOME/.local/share/open-tv. Expect to search for both names for a while.

Upgrade cost is low for store installs and slightly higher for source builds. The README states the project has been developed and maintained by one person for free over two years and asks for donations, which is worth knowing before you build a workflow around it. Upgrading a source build means Node, Rust and the Tauri CLI all have to be current, and the Dockerfile pins Node 22 and uses debian:trixie-slim as the base for both stages. If you build from source, that Dockerfile is the closest thing to a documented toolchain.

Editorial conclusion

Adopt Fred TV if you already have a legitimate M3U or Xtream subscription and want a desktop player that drives mpv directly, records while watching, and can re-stream a channel to another device. Skip it if you need a headless server, a browser-only client, or a player that bundles every dependency on Linux. Before committing, verify three things on your own machine: that mpv, ffmpeg and yt-dlp are present at the versions your distribution ships, that your provider's Xtream endpoint answers inside the app, and that the recording path has enough free space, since the README documents recording but says nothing about where files land or how large they grow.

Frequently asked questions

Official sources

1. Fredolx/open-tv on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases