Dispatcharr

Last reviewed Sep 13, 2026 · 742 words

Dispatcharr solves the problem that ends most IPTV-in-Jellyfin setups: the provider allows 2 connections, the household has 4 televisions, and the third stream kills the first. It sits between your M3U source and your media server, proxies the streams itself, enforces the provider's connection limit, and presents the result as an HDHomeRun tuner that Jellyfin or Plex accepts as if it were hardware. It is the newest project in this space, first released in 2024, and the trade for that is a project still changing shape under you.

What it replaces

Threadfin, and before that xTeVe, have been the standard M3U-to-HDHomeRun bridges for years. They work, they are light, and their web interfaces show their age. Dispatcharr's pitch is the same job with a modern React dashboard, a real database behind it, and stream management that goes beyond a simple proxy: channel groups, per-account connection caps, stream profiles that can transcode or pass through, and EPG matching that does not require hand-editing an XML file. If you have a working Threadfin setup that does what you need, there is no reason to migrate. If you are starting fresh in 2026, Dispatcharr is where the development energy is.

What it needs to run

Docker only, and the compose stack is heavier than the old bridges because there is a Postgres database and a task queue behind the web app. Plan on 512 MB of RAM as the floor and more if you enable transcoding profiles. The published image is on GitHub's registry and the web UI listens on port 9191 by default:

services:
  dispatcharr:
    image: ghcr.io/dispatcharr/dispatcharr:latest
    ports:
      - "9191:9191"
    volumes:
      - ./dispatcharr-data:/data
    restart: unless-stopped

Check the project's current compose example before copying; the all-in-one image bundles the database today, and the maintainers have already restructured the stack once. That is the practical meaning of "young project": read the release notes on every pull. The other requirement is the obvious one from the con list. Dispatcharr provides no content. You bring an M3U URL and an XMLTV guide from a provider you have a legitimate subscription with, or from a tuner of your own; the app organises what you give it.

The connection-limit feature is the reason to run it

Add each provider as an M3U account with its maximum stream count. Dispatcharr opens one upstream connection per channel in use and shares it with every client watching that channel, then refuses or queues the request that would exceed the cap, instead of letting the provider drop everyone. For a household where two people often watch the same news channel, that alone halves the upstream load. Combine it with channel groups so each television only sees the 40 channels anyone actually watches, rather than the 8,000-line playlist the provider ships.

EPG and channel matching

Guide data comes from one or more XMLTV sources. Dispatcharr matches channels to guide entries by name and by the tvg-id tags in the playlist, and lets you fix mismatches by hand in the dashboard. Get this right before pointing Jellyfin at it: Jellyfin pulls the guide through the HDHomeRun emulation and the XMLTV endpoint, and a channel with no guide entry shows as a blank slot that people assume is broken. If you have an existing TVHeadend for over-the-air tuners, Dispatcharr can sit alongside it and Jellyfin will list both as tuners.

The honest risks

A project this new has three. Breaking changes between releases, already covered. A community small enough that an unusual provider quirk may have no documented answer yet. And the Postgres dependency, which makes backups a database dump rather than a folder copy; script it. None of these are reasons to avoid it, but they are reasons to keep Threadfin's config around for a month after switching. The media server category has the wider live-TV field.

What I'd do

New live-TV setup in 2026: Dispatcharr, one provider account with the real connection limit set, a curated channel group per room, XMLTV matched and checked before Jellyfin sees it. Pin the image tag rather than latest, read release notes before updating, and dump the database nightly. If the project stalls, migration back to Threadfin is an afternoon, because the playlist and guide URLs are the only real state.