The Downloads view is one persistent queue for every kind of transfer rDownloader can do: direct HTTP, one-click hosters, Usenet articles, BitTorrent, media sites, galleries, livestream recordings and remote file transfers. They share the same priorities, the same speed limit, the same statistics and the same post-processing — there is no separate list per protocol.

The queue survives restarts. A transfer interrupted by a crash resumes from its last checkpoint rather than starting over.

Everything is grouped into packages. A package is the unit that carries a category, a priority, an archive password and a post-processing level; the files inside it inherit them.

Each package downloads into its own directory:

<storage root>/<category path>/<package name>/

Click the destination on the package header to copy the path to the clipboard.

A package header shows {finished} of {total} files finished, the number of active transfers — for a Usenet package the connections at work instead — the error count, its own speed and its own estimated time remaining. It has start, pause, extract, edit and delete actions, and expands to show the individual files. When unpacking or post-processing failed, its Extraction failed or Post-processing failed badge opens the package's post-processing steps with the failed step's reason in full.

Its menu also opens Collisions and duplicates: what happens when one of its file names is already taken, and which of its files already exist — see Name collisions and duplicates.

A package that came from an NZB can go to a provider from its menu too: under Hand to provider it lists your accounts whose provider takes NZB files (TorBox, Premiumize.me), in any state of the package — handy when it failed because your own Usenet servers no longer have the articles. The provider fetches the NZB itself and the finished files come back into the LinkGrabber as links, like every remote job. The package stays and shows a Handed to … badge that opens Remote jobs; it goes as soon as you forget or discard the job. Without such an account the entry is not shown; Show the hand-over in the Downloads under Settings → Interface → Display switches it off.

Where a metadata enricher found out more about a package — title, series, season, episode, year, rating, genre, runtime — it shows as chips under the name. Show metadata in the row above the list hides them; nothing is deleted, the choice is kept per browser, and they are shown by default.

A package you opened or closed stays that way in this browser, across reloads. The button beside Select all opens every package the filter and the search show, or closes them once they are all open; Open all packages and Close all packages in a package's menu do the same. A new package starts closed — Show packages closed in the Downloads under Settings → Interface → Display changes that. Jumping to a selected file still opens its package.

From a window of 560 px up, a slim header above the list names the columns — name, state, progress, size, and category and account. Drag the line at the left edge of the state, progress, size or category column to make it wider or narrower; every row follows. With the keyboard, tab to that edge and use ← to widen and → to narrow (8 px a press, Shift for 32 px); Enter or a double click puts that column back. The columns menu at the right end of the header has Reset all column widths.

The widths are kept in this browser, separately for the download list and the LinkGrabber. A widened column gives way before the name does: however wide you drag it, the name keeps at least 200 px, and a narrow window shrinks the widened columns back towards their usual width first.

Click a column name in that header — name, state, progress, size, or category — to sort the list by it: the packages, and the files inside each package. A second click turns the order around, a third goes back to the queue order. This sorts only what you see: downloads still run in queue order, and a notice above the list says so, with Back to queue order. While the view is sorted, the drag handles are hidden, because a sorted list has no queue position to drop on. The sort is kept in this browser.

A row is always in exactly one of fourteen states — Queued, Resolving, Downloading, Paused, Mirror, Retrying, Verifying, Repairing, Extracting, Blocked, Failed, Cancelled, Completed, Seeding. Transfer states explains each one and what moves a row between them.

A Usenet recovery volume held back until a repair needs it reads Postponed rather than Mirror. See Usenet and NZB.

A package is shown as finished only when every file in it has completed (or stood down as a mirror). While some files are there and the others wait, failed or are blocked, the package reads Waiting for missing files: its post-processing — unpacking above all — starts only once every file has arrived, so an archive is never unpacked with volumes missing. The file that completes last starts it. Usenet is the exception: a missing file there may be rebuilt from the recovery data, so post-processing starts once every file has settled.

Globally, from the Downloads toolbar. Every action there is an icon button: point at it, or reach it with the keyboard, and its tooltip names it with its key in parentheses — Direct job (A), Start all (P). The keys come from the shortcut list, so a key you change changes the tooltips and the menus' key hints with it. Only the file count and the time a timed pause holds stay text, and Start all keeps its colour.

• Direct job — or a on the Downloads page — opens a dialog for one link: paste a direct HTTP(S) link or a magnet, choose category, account, proxy and priority if you like, and Enqueue. The dialog closes once the link is queued; a refusal stays in it, with what you typed.

• Start all / Pause all — or press p from anywhere in the application. Pausing or resuming many files — the whole queue, a package, a selection — is one step for the service, so a queue of a thousand files pauses as quickly as one of ten.

• Pause for a while — the menu beside it (also on the transfer rail) pauses the whole queue for 30 minutes, 1 hour, 3 hours or until a time of day (today, or tomorrow if that time has passed). Nothing new starts meanwhile, a link you add waits too, and the button reads Paused until 14:30 with the time left in its tooltip. At the end exactly the downloads the pause stopped carry on by themselves; one you had paused before stays paused. The pause survives a restart, and an end that passed while the service was down resumes at the next start. A click on the button, or p, resumes now and ends the pause.

• Limit — the global speed limit in MiB/s. Empty means unlimited. It applies live; no restart, no re-queue.

• max — on the transfer rail beside N running: how many downloads run at once (1–32), the same value as Simultaneous downloads in the settings. A higher number starts more on the scheduler's next pass, within half a second; a lower one starts nothing new until fewer run, and stops none of the running ones.

• Live — the current combined rate of everything running.

• List housekeeping: Remove completed packages (also k), Remove failed packages + files, Remove all stopped packages, and — the only red entry — Clear the entire list.

Per package and per file, from their own rows: start, pause, cancel, remove, rename, extract, reset. Copy link (a file) and Copy links (a package — all its files, also the ones a filter hides) put the addresses on the clipboard, one per line. Open source page opens the page a media download came from in a new tab; it is offered only where that page is known. A file whose hoster plugin has a loaded version under test also offers Test with {name} v{version}, which starts that one download on the tested version — see Versions: running, under test, previous.

Stop mark — Set stop mark here in a file's or a package's menu pauses the queue once that file is done (finished, or failed for good), or once no file of that package is waiting or running any more. Downloads already running finish; nothing new starts, and the pause lasts until you resume — the control reads Stopped at the stop mark. There is one mark at most: a new one replaces the old. It belongs to its file or package, not to a place in the list, so it moves along when you reorder and disappears when you remove what it sits on, and it survives a restart. The marked row shows a stop sign, and the transfer rail names the mark with an × to remove it (also Remove stop mark in the row's menu). A file or package that is already done cannot be marked. A notification rule can tell you when the mark is reached (Stop mark reached, see Notifications).

A refused action says so. When a pause, resume, cancel, removal or delete is not possible — a state that does not allow it, another link to the file already downloading — the reason stays above the list until your next action or until you close it. Results come as short notices in the corner instead, and they say only what happened, not what was left alone. What went through leaves by itself; what was refused — a drag the list cannot take — stays as a yellow notice until you close it. A long package name in a notice wraps onto the next line instead of being cut off.

Directly above the list sits one row, built the same way as the one in the LinkGrabber, from left to right:

• Select all — once something is ticked, its label names what is selected, packages and files apart: 4 packages · 11 files selected, or 3 files in 1 package selected while one package holds them all. A package counts as soon as one of its files is ticked.
• Open all packages / Close all packages — one button, opening every package the filter and the search show, or closing them once they are all open.
• Search — narrows the list to the files whose name, or whose package's name, contains what you type; capitals do not matter. A package that matches keeps all its files. The field has no key: f opens the indexer search in the LinkGrabber instead.
• The filter: All, Active, Waiting (retries included), Paused, Failed (failed, blocked and cancelled files), Seeding, Completed. Filter and search stay in the address — /downloads?filter=failed&q=ubuntu opens the list just so, and a reload keeps it. When they hide everything, the list says so and offers Reset filter.
• Export all packages, the Show metadata switch, and the figures — packages and files.

Tick files or packages and the selection bar appears below that row, in one line: the badge with the same count (4 packages · 11 files selected; in a narrow bar the file count, both numbers in its tooltip), category, priority and post-processing level, then icon buttons in the same order as in the LinkGrabber — Start, Pause and Cancel, Show in list, Export — followed by those only Downloads has: Extract, Rename (one file), Re-resolve, and the two red ones that show their icon and how many they touch — Reset 3 files and Delete 1 package, offered when the selection holds something to reset or a whole package; their tooltips say what the figure counts. Remove comes last. Every icon names itself when you point at it or reach it with the keyboard. The × at the end clears the selection. Category, priority and post-processing level apply to whole packages, so the interface asks you to select all of a package's files.

Start not before… in a package's menu holds the package's waiting files back until a day and a time you choose; what already runs carries on. The row shows an alarm clock that names the moment, and Remove the start time lets the package go with the queue again. A moment that has passed holds nothing.

Download window… in a package's menu says when the package may download, week after week. Switch on Own download window and add time spans — weekdays and a part of the day, also past midnight; the first one offered is every day from 22:00 to 06:00, and there can be 28. The times are read in the time zone of the bandwidth schedule. Outside its window the package's waiting files wait, and its running downloads that can resume pause until the window opens again; what would have to start over runs to its end, as with the schedule's pause.

• A category can carry a window for its packages, set in the category editor. A package's own window replaces its category's as a whole; with neither, the package follows the bandwidth schedule alone. With Own download window off, the dialog says which of the two applies.
• Ignore the schedule's pause lets the package download while a bandwidth profile pauses downloads — one urgent download during the day. A window without time spans is just that exception: the package downloads at any time.
• No window makes a package faster. The global limit, the active profile's and the one set by hand still apply, and the strictest wins.

While a window applies, the row shows a calendar clock, in the warning colour while the window is closed; pointing at it names the spans (Outside its download window, waiting: …) or that the package ignores the schedule's pause.

While a bandwidth profile pauses downloads, the control beside Start all / Pause all and the transfer rail read Paused by schedule until 22:00; see Downloading only at certain times.

The REST API offers PUT /api/v1/packages/{id}/start-after and GET|PUT /api/v1/packages/{id}/download-window (the read also names the category's window and whether the window or the schedule holds the package right now), the MCP server set_package_start_after, get_package_download_window and set_package_download_window.

Three priorities: High, Normal, Low. Within a priority you set the order yourself — drag a row's handle, or focus the handle and use ↑ / ↓, so ordering works without a pointer.

The order survives a restart. Two moves are refused with a reason:

• Reordering while a filter or a search is active, because the hidden rows would end up somewhere you did not choose.
• Moving a package out of its priority tier — set the priority first, then order within it.

Downloads run in that order, and a short retry keeps its place. A file whose attempt failed and retries within ten seconds holds its place against every file after it in the list, so a passing error does not hand the slot down the queue and leave begun files behind in several packages. A file that has to wait longer — a hoster's limit, a wait the hoster states, a longer backoff — gives its place to the files after it meanwhile, and is ahead of them again once the wait is over.

Connections per host is a budget shared by every running transfer, not a per-file figure: chunks and parallel files of one hoster all count against it, which keeps hosters from answering with throttling or a refusal. www.example.com and example.com share one budget. 0 lifts it. Bytes per second is a separate budget; see Bandwidth and power.

A file whose host is full waits without taking a slot. A file starts while its host has a connection free; a file that is still starting counts as one, whatever its chunks. When the running files of a hoster hold all of its connections, the next file of that hoster stays Queued, says Waiting for a connection to <host> under its row, and leaves its Simultaneous downloads slot to the next file of another host; it starts as soon as the hoster has a connection free again. The files of a hoster whose link is served from another server — most one-click hosters and debrid services — count against that server's connections once they run, so they run side by side as far as Simultaneous downloads allows.

A change takes effect on the next job, without a restart.

A failed transfer is retried automatically. The default is 8 attempts, configurable from 0 to 100 under Settings → General. The wait between attempts backs off, from seconds up to five minutes, and a server's or a hoster's Retry-After is honoured rather than overridden, up to one day. From the sixth failed attempt in a row a file waits half an hour before the next one; the number of attempts still ends it.

A hoster's limit costs no retries. Waiting out a daily or rate limit or an IP block spends none of the attempts; the row shows Next attempt at with the time. A rate limit that names no reset waits an hour, unless the provider's plugin sets its own pause — most debrid and hoster API plugins wait 60 seconds after an HTTP 429 (see When a provider is busy). After 48 such waits in a row the download fails with The hoster’s limit was still in place after 48 waits.

When an account's traffic is used up. Some hosters give a premium account a traffic quota — DDownload, for example, answers You have reached the download-limit: 200000 Mb for last 1 days. The files that run into it wait as Retrying with the hoster's reason; they are not blocked, and the account is not called invalid. What else happens is set under Settings → General → When an account's traffic is used up, and can differ per account:

• Do nothing — only the files that ran into the limit wait; the account's other files still try and find out for themselves.
• Hold this account's downloads (the default) — the account's other files wait too; other accounts and hosters keep downloading.
• Pause the whole queue — nothing new starts; what is running finishes.

rDownloader checks the account every 15 minutes and continues by itself as soon as it reports traffic again, or when the hoster's wait ends (an hour for DDownload, whose window rolls, so traffic comes back a little at a time). Test in the account list checks at once. The pause control and the account list say whose traffic is used up and when the next check comes; the tray says so too. Continue anyway next to it, or starting the queue by hand, lets the hold go. A pause you set yourself is never lifted by any of this.

A file that is gone stays gone. When a hoster answers that the file no longer exists (404, 410), the download fails at once instead of spending its attempts; a file withheld for legal reasons (451) counts as offline and is tried again. A refused sign-in (401, 403) is reported as a problem with the account — or as a plain HTTP error where no account was used.

After the budget is spent the row rests in Failed with the reason. Reset, or starting the failed download again, gives it a fresh budget. With Retry failed downloads automatically on, a failure that may pass by itself — a limit, an IP block, an unreachable server, a file reported offline — comes back into the queue by itself after the interval you set; the row shows Next attempt at for the round that is due. See Your first download.

When one package holds several links to the same file, rDownloader downloads one and parks the rest as its fallback, shown as Mirror instead of an error. If the active link gives up for good, another takes over. A link backed by an account wins the turn, because it avoids the free-download limits.

The recognition is conservative:

• Only a name the source itself gave — or one the online check read from the server — counts as evidence. A guessed name does not.
• Sizes are compared with a tolerance rather than rounded into buckets.
• Archive volumes, Usenet files and torrent files are members of one download, not routes to it, so none of them are ever grouped as mirrors.

A waiting mirror can be promoted by hand. The whole feature can be switched off under Settings → LinkGrabber → General, where it is called Recognise mirrors.

If the link holding a group's turn fails for a reason that lies at the hoster — offline, gone, a limit, a login refused, a web page served instead of the file — the next mirror takes over by itself. The partial data of the one given up is discarded, so a file never mixes bytes from two sources, and the abandoned mirror's row says what happened and who took over.

A cause that lies on this machine never moves the job on: a full disk, a destination that cannot be written to, a file that could not be put in its place. A plain server hiccup waits for its retry on the same mirror.

Each mirror is tried at most once per attempt, also across restarts. A group that has run out ends with the reason the chosen mirror gave.

How a mirror group is formed in the first place is the LinkGrabber's business — see The LinkGrabber.

A mirror group is several downloads of which one runs. A file from a Metalink document (.meta4 or .metalink) is different: it is one download with every mirror the document names as a source, ordered by the document's priority and then by its order, with each mirror's location and protocol kept.

• When the document states a whole-file or piece hash, the chunks of the file come from several mirrors at once. Without a hash, one mirror works at a time and the others stand by.
• A mirror that fails hands its chunk to the next one, which continues from the last confirmed byte; the failed mirror waits out a backoff of 30 seconds, doubling up to 30 minutes, before it is asked again.
• A piece that does not match its hash excludes the mirror that sent it, and the file does not complete until another mirror has delivered that piece. A mirror that offers a different file size is excluded as well.
• A mirror pointing at this machine — a loopback address, the service's own address — is never requested, and neither is a link-local or cloud metadata address. A mirror in your own network is used only when you handed the Metalink document over yourself; a document that arrived otherwise cannot make rDownloader fetch from a machine behind your router.
• FTP and SFTP mirrors deliver chunks like HTTP ones, with the login stored for their host. The same address checks apply; an FTP server's passive-mode reply cannot redirect the connection elsewhere.
• Order, backoffs and exclusions survive a restart.

The details of such a transfer list its Sources: each mirror with its priority, what it has delivered, its failures and its state — Ready, Waiting (with the time it is asked again), Excluded (with the reason) or Not used yet. The same list is available as GET /api/v1/downloads/{id}/sources and through the MCP tool get_download_sources.

Reset discards everything about an attempt and starts it from zero: partial data, checkpoints, progress, the retry budget, the recorded error and the package's post-processing steps.

It works for every transfer kind and every state a job can rest in — including a finished one. A finished file is only deleted when the confirmation explicitly asks for it; otherwise the new attempt lands beside it under a collision-free name.

Available per row, over a whole selection, through the REST API and over MCP.

To start every stuck file over at once, use Reset failed in the Downloads header and pick Failed, Blocked or Failed and blocked; each entry shows how many files of the list — as the filter and the search show it — it takes. A package's menu has Reset failed and blocked files for that package alone. Both ask first and name the files. Cancelled files are left out: you stopped those yourself. Over the API the bulk action takes filter: { states, package_id } instead of ids, and the MCP tool control_downloads takes states and package_id.

A download stays with the plugin version that first resolved it, so an update never changes the rules under a file that is already running. The other side of that: a file that started with a faulty version keeps it. Re-resolve — in the selection bar, a package's menu and a file's menu, over the REST API and as the MCP tool reresolve_downloads — drops that binding and resolves the selected files at once with the plugin installed now, without starting a transfer: name, size and online status are written back before the download begins, so you see what a link is before it runs. A running file is paused for it and starts again after its own resolution; a finished file is left alone. Meanwhile the rows say Resolving now, and a notice counts the result — 3 resolved, 1 failed.

Only links with an account are resolved ahead. A hoster link without one would go through the hoster's free download, with its captcha and wait, so it is skipped, nothing is written, and the notice counts it — 2 resolved, 0 failed, 1 skipped (no account); it resolves at its start as before. A plain direct link is probed. A link that cannot be resolved in time, or not at all now, keeps its record and resolves at its next start; one the server reports gone shows that. Over the API and MCP, check_now asks for this resolution ahead, and the answer lists each file's result.

What is already on disk stays. When the new resolution names the same size and ETag, the file resumes where it stopped; when it names another, the file stops as blocked rather than mixing two files, exactly as any file that changed on the server does — Reset then starts it from zero. The choice is recorded in the audit log as a plugin version choice.

Packages leave as a link file and come back in through the LinkGrabber. Export is in the selection bar and in a package's menu; Export all packages in the row above the list exports every package of the list. Finished, running and failed files are exported alike.

Neither format carries a plugin, a plugin version, an account, a cookie or a token — a login or a key inside an address, such as an indexer's apikey, is left out too. That is the point: imported again, every link is assigned to its host anew and resolved by the plugin installed then — the way to move old links onto a new plugin version, or to another installation. Without a passphrase an .rdlinks file is readable, archive passwords included. A Usenet download has no address that works elsewhere, so an .rdlinks file carries its NZB, written from the articles rDownloader kept, and an indexer result in the LinkGrabber is fetched and carried the same way — the indexer's address and key stay behind. The export says how many entries it could not carry and names any NZB it could not get, with the reason; a .crawljob carries no NZBs. One file holds at most 2,000 links and NZBs, and 48 MiB.

The queue would rather fail a transfer than hand you a file that is not the file:

• A size that contradicts the hoster. When the length offered for the body disagrees with the size the hoster announced, the transfer fails instead of completing. Both numbers have to exist and to disagree by more than one percent, so a small file is never affected by rounding.
• A page instead of the payload. A resolved link whose response turns out to be markup fails and quotes the hoster's own wording.
• A remote file that moved. Size and validators are rechecked before a resume continues. If either moved, the partial file is kept and the transfer is refused rather than corrupted.
• A range request that was ignored. A server that answers a range request with the whole body is retried, and that host gets a single connection for the rest of the session.

Each of these carries its own translated reason, so the row says which one it was.

A single link that arrives with nothing but its hoster to go by is briefly named after the hoster; as soon as the resolver reports a real file name, the package takes the release name. This happens before the destination folder is created, so nothing on disk moves. A package you named yourself keeps its name.

The package editor can rename the folder too, with a switch beside the name; renaming the label alone does not move data. A folder name that is already taken is refused, and so is a package with a file still transferring.

The service measures the rate, so the web interface, the desktop tray, MCP and automations all show the same figure. A two-minute throughput history is charted in the queue summary.

Time remaining is derived from the current rate, per running row, per package and for the queue as a whole. It is left blank for an unknown total size, a paused transfer or a rate of zero. Entries that are waiting, verifying, repairing, unpacking or seeding stay out of the estimate; the "remaining bytes" figure beside it counts them and says so.

The statistics row carries active, queued, completed and failed counts, transferred and remaining data, the queue's remaining time, and free space per storage destination.

Those are the figures of the moment. The Statistics tab of Statistics & history holds the ones that survive a restart — see Statistics.

Finished packages can leave the queue by themselves after a configurable number of hours (Settings → General, off by default). Clearing the list by hand — Remove completed packages, Remove failed packages + files, Remove all stopped packages — works on whole packages: a package with a member still running, waiting, paused, seeding or being post-processed is kept, and the notice says only how many packages were removed. Remove all stopped packages takes every package that has stopped working, whatever the outcome — finished, failed or cancelled.

Clear the entire list removes every package, running ones included. Running and waiting downloads are cancelled and seeding stops before anything is removed; only a package that is being post-processed stays. Finished files always stay in their destination folder. The question says how many packages go and how many of them are still active, and offers Also delete partially downloaded files (off): ticked, it also deletes unfinished torrent data and the fragments a media download leaves beside its file. Incomplete files in the staging folder are removed by every removal anyway.

Deleting a package outright cancels running files and discards partial data, so it asks for a confirmation that names that cost. Anything still unpacking, still seeding, or — unless you say otherwise — holding a file that did not finish, stays where it is. Renaming a package or changing its priority does not restart its automatic-removal clock.

Under Settings → Services, each transfer service can be switched off individually: BitTorrent, Usenet, media downloads, galleries, stream recordings and remote file transfer. All are on by default.

A switched-off service:

• refuses matching links at intake, reporting how many links a paste lost, and
• moves anything it already had queued to Blocked with that reason.

Switching it back on returns those entries to the queue. Both take effect at once.

For plain HTTP(S) links the engine:

• downloads several files at once, and each file in several byte-range chunks;
• detects size, range support, ETag and Last-Modified, and resumes against those validators;
• completes atomically into the destination directory, with collision-free names;
• optionally generates SHA-256, and validates expected MD5, SHA-1, SHA-256 and CRC32 values.

Signed and expiring addresses are renewed before an interrupted download reuses its partial file — through the resolver that owns the link, or by one plain re-request of the original address. Neither runs JavaScript. When nothing can renew the address, the download is blocked with an explanation and the partial file is kept.

A download captured from a form-based browser download is repeated as a POST with its original body and user agent, and is never split into parallel chunks, because repeating it could trigger the site's side effect more than once. A POST the server will not resume is blocked rather than silently sent again, and can be restarted from the beginning as an explicit action.

The web interface raises browser notifications when links reach the LinkGrabber, when the queue completes, and when a download fails. This needs no desktop agent — grant the permission under Settings → Interface → This browser. Server-side delivery to webhooks, e-mail and Apprise services is a separate feature; see Notifications.

• The LinkGrabber — how links get here
• Transfer states
• Storage, categories and rules — where files land
• Post-processing — what happens after the last byte
• Statistics — the figures that survive a restart
• Download history — what finished or failed, after it left the list
• Bandwidth and power — limits beyond the global one
• Defaults and limits