Reporting Issues

Before reporting

1. Search existing issues — Your problem may already be reported or fixed in a newer version
2. Check the FAQ — Common questions are answered there
3. Try the latest version — Update to the latest release to see if the issue is already resolved. See Updating

What to include in a bug report

A good bug report helps us reproduce and fix the issue quickly. Include:

Required information

• Dubby version — Visible in the admin dashboard, or check with docker inspect dubbytv/dubby | grep -i version
• Deployment method — Docker Compose, Kubernetes, Unraid
• Host OS — e.g., Ubuntu 24.04, Unraid 7.0
• Steps to reproduce — What you did, step by step
• Expected behavior — What you expected to happen
• Actual behavior — What actually happened

For playback issues

• Client — Web (which browser + version), Android TV, Apple TV
• Media file info — Run mediainfo or ffprobe on the file and include the output
• Playback decision — If visible, include whether Dubby chose direct play, remux, or transcode
• Server logs — Include relevant log lines around the time of the issue:

  docker compose logs dubby --since 5m

For server issues

• Container logs — Full startup logs if the container won’t start
• Docker Compose file — Redact any secrets or API keys
• Environment — CPU, RAM, GPU model if using hardware transcoding
• Resource usage — Output of docker stats during the issue

What not to include

• Secrets and API keys — Redact SIGNING_SECRET, API tokens, and passwords
• Full database dumps — These contain user data and aren’t usually needed
• Unrelated log lines — Trim logs to the relevant timeframe

Feature requests

Feature requests are welcome. When suggesting a feature:

• Describe the problem — What are you trying to accomplish?
• Describe your ideal solution — How would you expect it to work?
• Note any workarounds — Are you currently solving this another way?