Four media sources appear inside Jellyfin clients
Remux v0.29.0 accepts 4 broad source types: Stremio add-ons, local files, WebDAV servers, and torrents. It exposes them through a Jellyfin-compatible API, so clients such as Infuse, Swiftfin, and Jellyfin for Android can connect without a Remux-specific player. The server also tracks playback, supports per-user library filtering, imports Jellyfin users and data, and has an admin dashboard. Music follows a separate pipeline that can use remote sources rather than depending on Stremio.
This mix solves an awkward self-hosting problem. A remote catalog, a local film folder, and a WebDAV share can live in one library view, while the client still speaks the API it already knows. Built-in torrent streaming removes a separate torrent client from the documented path. RemuxDB supplies audio and subtitle track metadata for streams. That external lookup is part of the experience, so a fully local library and a remote-source library have different availability and privacy assumptions.
What happened when we ran it
Our sandbox resolved 817 Rust packages in 38 seconds. The build ran for 664 seconds, then exited with code 101 when rust-lld reported that it could not find the native xdo library. The final warning also said DASHBOARD_PATH was unset, so the dashboard would not be embedded, and WEB_PATH was unset, so Jellyfin Web would not be embedded. The missing library was the compiler error that stopped the build.
Tests ran separately for 386 seconds and ended with exit code 101 at the same link failure. Rust-lld again could not find -lxdo, this time while compiling the remux-desktop test binary. The runner then waited for other jobs to finish, but it did not produce a passed or failed test count. Our fresh Debian container had 3 CPUs, 12 GB of RAM, no secrets, and no elevated privileges. The log does not identify any further cause.
The source quickstart omits the libxdo requirement
Our 817-package source run needed more than the 5 actions in the development guide: install cargo-make, install the Dioxus CLI, copy .env.example, build Jellyfin Web, and run cargo make dev. The sample environment points to a SQLite database and separate dashboard and web build directories. That explains the repository workflow, but it did not prepare our Debian image for the desktop crate's native xdo link. Linux source builders need to identify and install that requirement themselves.
Packaged use looks easier. The README links desktop builds for Apple Silicon macOS, x86_64 Linux, and x86_64 Windows. Its Docker example publishes port 3000, mounts /data, and pulls either the latest or nightly image from GitHub Container Registry. Those routes may avoid compiling 817 packages locally. They still leave the operator responsible for persistence, reverse-proxy policy, updates, media permissions, and the credentials entered for remote sources.
Jellyfin compatibility has playback exceptions in v0.29.0
Open issue 438 documents a precise gap in v0.29.0: the direct-play endpoint ignored an HTTP Range request for a remote MKV, returned status 200 from byte 0, and prevented forward seeking. The reporter said transcoded HLS seeking worked, which narrows the problem to direct play in that setup. A matching pull request was open when checked. Anyone choosing Remux for remote playback should test seeking, pause and resume, subtitles, and codec selection on each client.
Issue 449 reports a different v0.29.0 mismatch. Playback can use a selected alternate version, while the web download action and copied stream link still choose the top version. That can return the wrong file without visibly breaking the request. The current release notes contain several fixes for direct-play selection, codec profiles, subtitle burn-in, and metadata fallback, evidence that compatibility work is active and that the surface is wider than a successful login screen.
SQLite contains unencrypted working credentials
GitHub listed 47 issues, and issue 241 says SQLite rows hold live session tokens, full admin API access, add-on password fields, and future integration credentials without encryption. The report describes this as a local data exposure rather than a remote exploit: someone who obtains the database through a backup, snapshot, or copied data directory could receive working credentials. That distinction matters, but it does not make the finding harmless for a server whose purpose includes connecting to remote accounts.
A careful deployment should limit access to /data, protect backups, and avoid reusing credentials that grant broad access elsewhere. Encryption inside the application would still need an operator-managed secret, which the issue notes as an unresolved design choice. Until that work lands, the safest trial uses disposable add-on or WebDAV credentials and a private network. The AGPL-3.0 license permits inspection and modification, although running a patched fork also makes update tracking your job.
v0.29.0 is active, with 47 open issues
Release v0.29.0 arrived on September 3, 2026, and the repository was pushed again on September 8. GitHub showed 472 stars and 61 combined open issues and pull requests. Splitting the API results produced 47 issues and 14 pull requests. Several reports and fixes were updated during the same week, so this is a live project with a busy queue rather than a finished media appliance. Fast change raises the value of pinned images and a rollback copy of the SQLite data.
Jellyfin remains the safer choice for a conventional local library and a larger established ecosystem. Stremio Web is more direct when add-ons are the whole point, while Plex trades open-source control for commercial clients and account services. Remux is the interesting middle option. Its 38-second dependency resolution was encouraging, but the two linker failures, current playback exceptions, and plaintext credential issue set the adoption terms: use a packaged build, isolate its data, and prove the client paths your household depends on.