Repository navigation
remote jobs
Most things rDownloader does happen on this machine. A remote job does not: you hand a
magnet, a .torrent or an .nzb to a provider account, the provider fetches it, and when it is
done the finished addresses come back here as ordinary links. The job keeps running while this
machine is asleep, and the provider keeps it in your account afterwards until somebody deletes it.
Open Remote jobs from the sidebar or with 5.
Six bundled plugins run jobs, one per provider. Each needs an account for its provider under Settings → Accounts — see Hosters and accounts for setting each one up.
| Provider | Takes | Picks files at the provider |
|---|---|---|
| Real-Debrid | Magnet, .torrent
|
Yes — the job stops and asks |
| TorBox | Magnet, .torrent, .nzb, web link |
No |
| Premiumize.me | Magnet, .torrent, .nzb, web link |
No |
| Put.io | Magnet, .torrent
|
No |
| Offcloud | Magnet, web link | No |
| Seedr | Magnet, .torrent
|
No |
What has been tried against a real account. Premiumize.me has: a magnet, an NZB, a
.torrentupload and deleting a job at the provider were each confirmed on a live account. The other five follow their providers' published APIs but have not yet been run against a live account. If one of them misbehaves, the diagnostic bundle is the most useful thing to send.
Provider specifics:
-
Put.io and Seedr take a
.torrentas the magnet it is equivalent to — same info hash, name and trackers — because their API takes one address. A torrent with no trackers and no peers reachable over DHT cannot start that way. -
A
.torrentreaches the provider up to 8 MiB. Premiumize.me takes a file of up to 4 MiB; a larger one is not offered to a Premiumize.me account at all. - Seedr's API is a premium feature by Seedr's own terms. A plan without it is refused with its own message.
- Premiumize.me counts a transfer that is seeding as finished; it goes on seeding at Premiumize afterwards. After a crash rDownloader cannot ask Premiumize whether a job already arrived, so only the local duplicate guard below protects against a second one.
- TorBox runs torrents, Usenet downloads and web downloads in one account; the kind of what you hand over decides which.
Whether a provider already holds something shows before you hand it over. TorBox answers for torrents, Usenet and web downloads, Premiumize.me for magnets: the LinkGrabber asks one account per provider before its online check, and a link the provider holds ready carries the cached chip, naming the provider in its tooltip. Asking changes nothing in your account. See The LinkGrabber.
The form under Remote jobs offers only accounts whose provider has such a plugin installed. With no fitting account it says None of your accounts belong to a service with an installed remote-job plugin. If the plugin is removed while the form is open, the job is refused with No installed plugin can run remote jobs on this provider.
A remote job is a request the provider carries out over minutes or hours, and it leaves something in your account whether or not this machine is still listening. So:
- It has a vocabulary of its own, not the queue's states.
- It can stop and ask you a question, and nothing moves until you answer it.
- Ending it at the provider and removing it from this list are two different actions.
The page before an account with a remote-job service exists. With one, the form for the account, a magnet address and one or more .torrent/.nzb files appears in place of the notice.
The form on this page takes the account and either a Magnet address or files:
Or .torrent/.nzb files picks one or several from disk, and files dropped anywhere on the page
land in the form too, not in the LinkGrabber. Each file becomes a job of its own, handed over
one after another. Every file has a row with its state in words — Waiting, Being handed over,
Handed over, Already running, Failed or Not sent — and Remove the file takes one back.
A file may be at most 16 MiB; one that is larger or not a .torrent or .nzb is listed as
not sent, with the reason, and never read. Confirm with Hand over. A file the provider refuses
keeps its reason on its row, and the others go ahead regardless.
A file keeps its name at the provider, so two containers sent at once arrive as two transfers with their own names and folders. A job added without a file name uses the release name the container states plus a tag from its content.
While it loads, the form says Reading which of your accounts can take a job….
An NZB already in the LinkGrabber goes over from there, without picking the file again: its Hand to provider menu — and the same in the bar that appears when NZB imports are selected — lists your accounts whose provider takes NZB files, today TorBox and Premiumize.me. rDownloader writes the NZB back out from what it imported (files, articles, password and name), so it reaches the provider as the same release. The import stays in the LinkGrabber with a Handed to TorBox badge that leads here, so it is not queued twice by accident; queueing it is still possible and then downloads it on this machine as well. Removing the job from this list removes the badge. See The LinkGrabber.
An ordinary web link — for the providers that take one — is handed over through the REST API or the MCP server; the form takes a magnet or files.
The same content twice is one job, not two. rDownloader recognises the magnet or file locally and refuses a second job for the same content on the same account: This account is already running a job for that content. Nothing was sent a second time. That is the guard working, not a failure — a provider would otherwise keep a second copy in your account.
If the service crashes between handing a job over and hearing back, rDownloader first asks the provider what it already holds for that content before handing anything over again. After two attempts it stops: After two attempts the provider named no job, so nothing more is sent. Whether the attempts left anything in the account is worth a look before trying again. Check your account at the provider before you retry.
| State | What it means |
|---|---|
| Being handed over | The job is on its way to the provider |
| The provider is preparing it | Accepted, not yet fetching — converting a magnet, unpacking, whatever the service does first |
| Waiting for your selection | It stopped and wants to know which entries you want. Nothing moves until you answer |
| Fetching at the provider | Running there, whether or not this machine is on |
| Finished | Done; the addresses went to the LinkGrabber |
| Failed | The provider gave up. Terminal — the row stays so you can see what happened |
| Deleted at the provider | Ended inside your account on a confirmed request. The entry stays here and records that it was |
Each row is named after what you handed over: the .torrent or .nzb file name, a magnet's
display name (its dn), or the last part of a web link's address. Only a source without any name
— a magnet without dn, a link ending in / — is shown by its Identifier, the info hash or
digest the provider knows the content by. Beside the name the row says what it is in a word —
Torrent, NZB, Magnet, Link, or File for a file handed over without a name —
and which account runs it. Below it: the Identifier (click it to select it for copying), what
the provider calls the job (Known there as) and when it started.
A running job is asked for its progress every five seconds to fifteen minutes, as the provider suggests. A job waiting for your selection is not polled at all; answering it puts the row back on the clock.
Only Real-Debrid asks. The other five providers fetch the whole of what they were given and have no way to leave a file out, so their jobs never wait for a selection: when they finish, every file arrives in the LinkGrabber as one package, with its name, size and folder, and you pick there — still before anything is fetched to this machine. rDownloader never deletes files in your account to fake a selection.
A Real-Debrid job can stop and offer its contents — Entries the job offered on the row opens the list. Each entry shows where it sits inside the job as a path, its size where the provider stated one and Size not stated where it did not, and a Suggested mark where the provider already considers it picked.
Suggested is a default, not an answer. A provider that preselects everything is showing you what it would do, not what you asked for.
Tick what you want and press Send the selection. Then:
- At least one entry has to be picked. An empty selection is refused with Pick at least one entry.
- Only entries this job offered can be picked; a list that reorders itself cannot change what your selection means.
A job that stops to ask and then offers nothing to choose from is failed.
A job you answered never goes back to waiting for your selection. If the provider asks again,
the job is ended as Failed with The provider asked again after the choice was made (code
remote_job.choice_not_kept).
When the job finishes, the addresses it produced go to the LinkGrabber as one batch, labelled with the plugin's name, in one package per job — named after the file the job was added under, where it came from a file.
- They are addresses, not bytes, downloaded through the ordinary resumable queue — with retries, bandwidth limits and post-processing exactly as a pasted link has them.
- Where a provider's download links expire, a fresh link is fetched for every attempt, so a download that waits or is paused still works.
- They are treated as a pasted list: the online check runs, the blocklist applies, and the routing rules pick the category.
- Each address keeps the path it had inside the job, so the package structure survives.
- Only
httpandhttpsaddresses are taken, at most 500 of them; anything else is dropped. - A job that finishes with nothing is a failure: The remote job finished with nothing to download.
The row records the package it produced and links to it: Package “…” in the LinkGrabber opens the LinkGrabber with that package in focus while it waits there; once it has gone on — queued or removed — the link reads The package has left the LinkGrabber – go to the download list. A finished job is never polled again.
Two actions, and the difference is the point of this section.
Remove this entry from the list? This removes the entry here and nothing else. Whatever the provider holds stays in your account, untouched.
This is local housekeeping. Afterwards the confirmation reports exactly that: The entry was removed. Nothing was deleted at the provider.
Delete this job at the provider? This deletes the job inside your provider account. It happens outside this machine and cannot be undone. The entry stays in this list afterwards and records that it was deleted.
This and Discard at the provider and clear below are the only actions that remove something from a provider account:
- It is never triggered any other way — not by deleting the local package, a failed job or a cleanup.
- The dialog names the account. An API client must confirm explicitly, or is refused with Deleting a job at the provider has to be confirmed explicitly.
- The row stays as Deleted at the provider, still naming the job the provider knew, so you can see which request removed it and when.
- Asking again is refused with This remote job has already been deleted at the provider.
Deleting the account a job runs on takes its rows with it — that is a local deletion and touches nothing at the provider.
Above the list, two filters narrow it: All providers or one provider, All states or one state. A filter that hides every job says No job matches this filter., with Reset filter. The filters are part of the page's address, so a reload or a bookmark keeps them.
Clear list in the card's header acts on exactly what the filters show, in the same two ways as a single job:
- Clear the list here only removes the rows and sends nothing anywhere. Its question names how many jobs go and at which providers, and says that whatever the providers hold stays untouched in your accounts.
- Discard at the provider and clear (red, set apart) first deletes each job in your account at its provider, then removes its row. Its question names the count and the providers and says that this happens outside this machine and cannot be undone. A job that names nothing at the provider — never handed over, or already deleted there — only loses its row.
Both leave jobs still running alone — Being handed over, The provider is preparing it and Fetching at the provider — and the question says how many stay. If a provider cannot delete a job, that job stays in the list and the message says why; every other job is cleared all the same. Each clear is recorded in the audit log as Remote jobs list cleared, with the filter and how many jobs went, stayed and were left running.
Over the API the same is POST /api/v1/remote-jobs/clear with confirmed: true, optionally
at_provider, provider and states. An AI assistant uses clear_remote_jobs, which asks you
first and only clears the list here: deleting at the provider is never done over MCP, only in
the web interface.
- Picking files at the provider is offered by Real-Debrid only. For the others, the selection happens in the LinkGrabber, as described above.
-
A
.ccfcontainer is not handed to Premiumize; it is refused. - Nothing is scheduled. A remote job starts because you started it.
- The plugin never sees the account's credential.
- BitTorrent — the engine that fetches a torrent on this machine instead
- Hosters and accounts — the provider accounts a job runs on
- The LinkGrabber — where a finished job's addresses arrive
- Transfer states — the queue's own vocabulary, which is a different one
- Glossary