Can someone help me with Dispatcharr?

General
1

I’m having trouble with Dispatcharr and can’t figure out what went wrong. It was working before, but now I’m running into issues and I need help troubleshooting the setup, errors, or anything that might be causing it. I’m looking for advice so I can get Dispatcharr working again.

2

Start with the basics, because Dispatcharr usually breaks for boring reasons.

  1. Check the logs first.
    Look at container logs or app logs. If you use Docker:
    docker logs dispatcharr --tail 200

Watch for 3 common failures:

  1. database connection errors

  2. bad file permissions

  3. source or tuner auth failures

  4. Verify recent changes.
    If it worked before, something changed. Most often:

  • app update
  • host reboot
  • IP change
  • mounted path changed
  • token or password expired

  1. Test your mounts and storage.
    A lot of Dispatcharr issues come from paths. Make sure your media path inside the container matches what Dispatcharr expects. If the app points to /media but Docker mounts /mnt/media, it will fail or look empty.

  2. Check permissions.
    Run:
    ls -lah /your/media/path
    id inside the container
    Your app user needs read and write access. Broken perms bite ppl all the time.

  3. Confirm network access.
    If Dispatcharr pulls from IPTV, HDHomeRun, xTeVe, Plex, Jellyfin, or other sources, test each endpoint by IP and port. Example:
    curl http://source-ip:port
    If that times out, the app isnt the first problem.

  4. Check DB health.
    If you use Postgres or SQLite, make sure the DB file or service is present and writable. Corrupt DB after a crash is a thing.

  5. Roll back if an update caused it.
    A fast test is pinning the previous image version.

Post the exact error, your install method, Docker compose if used, and logs. Without those, ppl are guessing.

3

If the logs dont show anything obvious, I’d check the stuff around Dispatcharr, not just Dispatcharr itself. @waldgeist covered the usual suspects, but one thing ppl miss is time drift. If your host/container clock is off, auth tokens and guide pulls can start failing for no aparent reason. Check date in both host and container.

Also, inspect env vars actually loaded by the container. I’ve seen compose files look right, but an old .env or stale container keeps bad values:
docker inspect dispatcharr | less

Another angle: browser-side weirdness. If the UI loads but acts broken, open dev tools and look for 401/403/CORS errors. Sometimes the backend is fine and the frontend is just calling the wrong base URL after a reverse proxy change.

If you use nginx, Traefik, or Cloudflare, temporarily bypass it and hit Dispatcharr directly on the local IP:port. Reverse proxy headers break stuff more often than ppl admit.

And maybe unpopular take, but I would not roll back imediately unless you know an update caused it. That can muddy the waters if config/data already changed. First figure out whether it’s startup, playback, EPG, or tuner discovery that broke. Those are very diff problems.

Post:

  • what “not working” means exactly
  • screenshot of the error
  • compose/env with secrets redacted
  • whether it fails on direct access too

Otherwise everyone’s just throwin darts.

4

I’d separate this into app problem vs data problem first, because people waste hours chasing the wrong layer.

A fast test for Dispatcharr:

  1. Stop the container
  2. Start it with a fresh empty config directory
  3. Add just one source / one tuner / one basic setting
  4. Test again

If it suddenly works, your issue is probably corrupted state, bad cached channel data, or an old migration that half-applied. That happens more than people think after updates or interrupted writes.

I slightly disagree with the instinct to focus on networking first unless the symptoms clearly point there. If Dispatcharr starts, loads, and only certain features fail, I’d suspect the database/config before proxy issues.

Also check:

  • disk space and inode usage
  • file permissions on mounted volumes
  • sqlite/db lock errors
  • duplicate container names or old orphaned compose services
  • healthcheck status restarting in a loop

docker ps -a
docker logs --tail=200 dispatcharr
df -h
df -i

@waldgeist already covered the outer stack angle well. I’d add that restoring yesterday’s config backup into a test instance is often the quickest proof.

Pros of Dispatcharr: pretty flexible, decent for self-hosted IPTV workflows.
Cons: troubleshooting gets messy when config, proxy, and provider issues overlap.

If you post the exact failure point, people can narrow it down fast.