Repository navigation
torrents
rDownloader embeds a BitTorrent engine (librqbit) — no external client is needed. Magnets and
.torrent files go through the same LinkGrabber review as everything else and end up on the same
queue.
Settings live on their own page, Settings → BitTorrent; per-torrent controls are in the torrent's detail view, which has tabs for files, trackers, peers and seeding.
Sharing data with other peers is off by default. A new installation uploads nothing — not even while a torrent is still downloading. Downloading without ever uploading is unfair to the swarm and gets clients banned from some private trackers, so decide for yourself whether to turn it on. Category and per-torrent overrides cannot re-enable sharing that is globally off.
- Paste a magnet link — into the Downloads input for a direct add, or into the LinkGrabber for review. A magnet resolves its metadata on demand, without starting a transfer, and is then reviewed exactly like an uploaded file.
- Upload or drop a
.torrentfile — limit 16 MiB. Metadata is validated before queueing. - Drop
.torrentfiles into a watched folder, in review or direct-queue mode. - Paste an ordinary link that turns out to serve a
.torrent: the online check recognises it and names it after the torrent itself — see Recognising what a file really is. The.torrentis fetched with the link's authentication profile and through your proxy, and kept for the download.
The complete file tree, the name and the total size appear in the LinkGrabber before you commit to anything.
Each torrent gets its own package directory.
The file tree offers folder tri-state selection: individual files and whole folders can be excluded, and the selected total size updates as you choose. Deselected files are neither downloaded nor preallocated.
You can still change the selection on a running torrent; it takes effect immediately.
Each file has a priority tier: high, normal, low or skip. On top of that,
comma-separated exclusion patterns apply — *.nfo, extras/*, **/sample.mkv. Saving them
marks each dropped file with Excluded by the pattern …; clearing the field is the undo.
When selection, patterns and priority disagree:
- An explicit per-file decision beats every pattern.
- Patterns only touch files you never decided yourself.
-
skipis equivalent to deselecting. - A pattern-excluded file keeps its priority, so re-including it restores the previous state.
The tracker tab lists the torrent's trackers in BEP 12 tiers. You can view, add, remove and reorder them, force a fresh announce (rate limited to once a minute), and refresh scrape counters over HTTP (BEP 48) or UDP (BEP 15).
Counters carry the time they were fetched and are marked stale after fifteen minutes rather than being presented as current.
Live per torrent: share ratio, uploaded bytes, transfer rates, connected peers and piece progress; in the detail view also the peer list and piece availability. Values from a torrent that is no longer running are marked as not live.
Seeding sits inside the global data-sharing switch — with sharing off, nothing seeds.
The policy inherits global settings → category → torrent, and each of the three values — enabled, target ratio, seed time — inherits independently. The effective value and the level it came from are shown per torrent, and either override can be set or cleared on its own.
Defaults: seeding disabled; target ratio 1.0 once seeding is enabled; upload limit unlimited.
Seeding also follows the general upload limit: the stricter of that limit and the torrent upload limit applies.
Seed time keeps counting across restarts, and ongoing seeding resumes after one.
Under Settings → BitTorrent:
- Active torrent downloads — how many torrents download at once (1–32, default 4); the rest wait in the queue. The queue's general limit on active downloads still applies on top.
- Active seeds — how many finished torrents seed at once; empty means no limit. Past it, the torrents that have seeded longest finish first, so newly finished ones get their turn. A seed whose data is still being checked counts, but the limit never ends it.
Recheck in a torrent's menu hashes its data against the torrent's pieces again — for example after you replaced files by hand. A seeding torrent is checked at once and keeps seeding; a running one stops briefly, is checked and runs on; any other is checked the next time it starts. While the check runs the panel shows Checking data… n %; afterwards it says whether all data was intact or how much of it was, and pieces that no longer match are downloaded again. No ratio or time limit ends a seed while its data is incomplete — Stop seeding still does.
Change location… moves a seeding or paused torrent's files, together with its package folder, to another place, and the torrent carries on from there without being added again. Pick a storage root and, optionally, a folder inside it; the package keeps a folder of its own name there, just as when it was queued into a category.
- Another disk is fine: the files are copied, each copy is compared with its original, and only then do the originals go. Before it starts, rDownloader checks that the copy fits and leaves the storage root's free-space threshold.
- While the files move, the torrent does not seed and its panel says where they are going. After the move it checks its data once at the new place and seeds on.
- If anything fails, everything stays at the old place and the panel says why.
- If rDownloader stops in the middle of a move, the next start finishes it or takes it back — never half and half.
- A package that holds other downloads as well cannot follow the torrent, and a folder that is already there is refused.
| Control | What it does |
|---|---|
| Interface binding | Binds all torrent sockets to one network interface (Linux and macOS) |
| Kill switch | Pauses every torrent within ten seconds of that interface disappearing, and resumes exactly the torrents it paused when it returns |
| IP blocklist | Loaded from an http(s) URL |
| Peer transports | TCP, uTP, or both |
| Peer limit | Per torrent |
| Upload / download limits | Global, on top of the queue's speed limit |
| SOCKS5 peer proxy | Routes outgoing peer connections through an existing proxy profile |
| Listen port | Random by default; configurable |
| UPnP | Port forwarding for the listen port, with a separate announced port for routers that map to a different external one |
Interface binding plus the kill switch is the combination that makes a VPN tunnel safe.
The Network status card at the top of Settings → BitTorrent shows what the engine is doing right now:
- the bound interface, and whether it is present or missing;
- the kill switch: off, armed (it would pause within ten seconds), or engaged — every torrent is paused until the interface returns;
- a failed session rebuild after a saved change, with its reason — the previous session keeps running;
- a peer proxy that cannot be resolved — without it the session does not start;
- Port in use — another program holds the listen port, so the engine does not listen there.
The refresh button reads it again. While the kill switch holds the torrents, Downloads shows a warning naming the interface that went, with a button to this card; it disappears on its own once the torrents run again.
The kill switch checks again on every pass while the interface is gone: a torrent that still carries traffic is paused again, and one the engine refuses to pause is named in the log. A torrent you stopped yourself stays stopped when the interface returns, and a refused resume is tried again.
The SOCKS5 proxy covers peer connections only — tracker and metadata traffic is not routed through it, and the setting says so.
A failed UPnP mapping never blocks outgoing downloads.
Test port (field Port test in Settings → BitTorrent) checks the incoming port with the saved settings, from this machine alone — no outside service is asked. The answer is one of:
| Result | Meaning |
|---|---|
| Reachable | A peer has connected in through the port — the internet reaches it |
| Listening | The port answers here, but no peer has connected in yet; whether the internet reaches it is unproven. Check the router's forwarding or UPnP, then test again while a torrent runs |
| Not listening | The engine is not listening for incoming peers |
| Could not be started | The torrent engine could not be started; the reason follows |
| Another program holds port … | The listen port is taken by another program, so the engine does not listen there. Choose another port or close that program |
Below it, the test names how many torrents run and how many peers connected in. A peer proxy carries outgoing connections only; incoming peers always arrive directly.
Changes to port, interface, proxy, blocklist and transport take effect on save, without a restart. If applying them fails, the previous settings keep running.
A port another program holds is refused, not shared. Before the engine listens on a fixed port it checks that the port is free. When another program — another torrent client, say — holds it, the engine does not start beside it: saving says Another program holds port 6881, so the torrent engine does not listen there; saved settings stay saved. Choose another port or close that program., and the port test and the network status card say the same.
Removing a torrent download — however it leaves the queue, including through the compatible APIs and the MCP server — also stops the engine from running it; it does not come back at the next start.
Removing never deletes what a download already wrote: its files stay in the package folder, as for every other kind of download.
Stored .torrent metadata can be deleted automatically after completion.
The interface disables what the engine cannot do, and the API rejects it with a stable error code
(GET /api/v1/torrents/capabilities lists what is supported). Known limitations:
- File priorities are emulated by opening one tier at a time rather than being native, so files within a tier still download concurrently.
- Not available: sequential download and first/last-piece prioritisation — the engine has one fixed piece order (files by name, each file's first and last piece, then front to back) that cannot be switched — as well as protocol encryption (MSE/PE), separate proxies per traffic class, NAT-PMP and PCP.
- BEP 19 web seeds are parsed and displayed but never fetched.
- No speed limit per torrent: the engine takes a torrent's rates only when it adds the torrent and cannot change them later, so a package holding a torrent takes no limit of its own; the session-wide limits apply.
A magnet or a .torrent can also be handed to a provider account — Real-Debrid, TorBox,
Premiumize.me, Put.io, Offcloud (magnets only) and Seedr — which fetches it there; the finished
files arrive in the LinkGrabber. See Remote jobs.
Settings → Services → BitTorrent. Matching links are then refused at intake and anything already queued moves to Blocked with that reason; switching it back on returns them to the queue.
- The LinkGrabber
- The download queue
- Watched folders
- Automation tool compatibility — the qBittorrent-compatible API for Sonarr and Radarr
- Remote jobs — a magnet fetched at a provider instead of here
- Bandwidth and power