Skip to content

Docker/libtorrent - #43

Closed
tsaridas wants to merge 6 commits into
stremio-native:masterfrom
tsaridas:docker/libtorrent
Closed

tsaridas wants to merge 6 commits into
stremio-native:masterfrom
tsaridas:docker/libtorrent

Conversation

@tsaridas

@tsaridas tsaridas commented Sep 8, 2026

Copy link
Copy Markdown

View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.

Mirrors the release.yml CI build (Debian/Ubuntu base, libtorrent 2.1.1
built from source, --features libtorrent --no-default-features) using
cargo-chef for layer caching. Runs the server binary headless via
--no-tray since the release build defaults to tray mode.
tray.rs embeds icons/icon_48.png via include_bytes! at build time, so
excluding icons/ in .dockerignore broke the build. Also expose/publish
the default BitTorrent listen range (42000-42010) instead of a vague
"ephemeral port" note, based on what /settings actually reports.

Verified end-to-end on the target host: docker build succeeds, the
container starts headless, and /heartbeat, /settings, /stats.json all
respond correctly with the libtorrent backend active.

Document Docker usage, how to point a Stremio client at the server
(there's no bundled web UI), and how to configure libtorrent via the
/settings API in the README.
Cover the env-var port overrides (STREAM_SERVER_HTTP_PORT/HTTPS_PORT/
PUBLIC_BASE_URL) needed for --network host when the default ports are
already taken, the built-in ratatui TUI stats dashboard (--tui, attach
via docker attach), and a fast-playback /settings tuning example.

This matches an actual deployment on the target host: replaced an
untracked ad hoc stream-server:dev container (bridge networking + nginx
port-remap trick) with this Dockerfile's build running --network host,
reusing its existing data volume, with GPU passthrough for hardware
transcoding and the TUI enabled.
Every field on ServerSettings (BitTorrent connection/privacy/proxy
options, cache size, proxy-streams, seeding) is now overridable with a
STREAM_SERVER_* env var, read once when constructing the default
settings on first startup (before any settings.json exists) -- after
that, settings.json and the /settings API are the source of truth.

Also retunes a few shipped defaults for a single-stream home
connection in the ~100Mbps class:
- bt_allow_multiple_connections_per_ip: false -> true (more usable
  connections behind CGNAT/shared-IP swarms)
- bt_min_peers_for_stable: 5 -> 3 (starts playback sooner)
- bt_download_speed_hard_limit: 0 (unlimited) -> ~11.25MB/s (~90% of
  100Mbps), the one speed-limit field actually wired to libtorrent's
  download_rate_limit; leaving headroom avoids bufferbloat that would
  otherwise hurt both playback smoothness and other traffic on the
  link. Set to 0 via env/settings to go unlimited.
- bt_max_connections stays at its existing default (800): per-torrent
  connections are separately clamped to 200 once the global max
  reaches 800 (see TorrentSpeedProfile::effective_connection_limits),
  so raising it further doesn't speed up a single stream -- it only
  matters when running several torrents concurrently.

Verified on target: env vars applied correctly on a fresh volume,
persisted settings.json still takes precedence once one exists.
Table the concrete env vars and rationale for the 100Mbps-tuned
defaults (bt_max_connections, bt_min_peers_for_stable,
bt_allow_multiple_connections_per_ip, bt_download_speed_hard_limit),
note that bt_download_speed_soft_limit is currently a no-op in the
libtorrent backend, and cross-reference the --network host example.
@tsaridas tsaridas closed this Sep 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant