Beyond the single speed limit in the Downloads toolbar and on the transfer rail, rDownloader has scoped bandwidth limits, traffic budgets, a weekly schedule, quiet hours, and actions that run when the queue drains.

It sits on two settings pages:

• Settings → Bandwidth — three tabs: Status & limits (what applies now, and the download and upload limits set by hand), Profiles (scoped limits and traffic budgets) and Schedule.
• Settings → Unattended operation — quiet hours, what happens once the queue is empty, and pausing on battery or a metered connection.

The reconnect script is neither: it lives under Settings → Network → Reconnect.

A profile bundles:

• a global download rate,
• an optional upload rate,
• a parallelism cap,
• traffic budgets,
• Pause downloads — while the profile is in force, downloads wait; see Downloading only at certain times.

Profiles are reusable, and a weekly schedule decides when each one applies. Each profile's line in the list names its monthly and daily budget, its parallel-file cap and its upload limit, so a profile with only a budget does not read as Unlimited, and one that pauses downloads says pauses downloads.

On top of the global rate, limits can be set per protocol, host, provider account and category.

A transfer is subject to every limit that applies to it, so the strictest applicable limit wins. The status names which limit it was.

The speed limit you set by hand in the Downloads toolbar, or on Status & limits, is a limit of its own: it survives every profile switch, and whichever of the two is stricter takes effect.

A single package can have a download limit of its own: in Downloads, open Edit package on the package and enter a Speed limit for this package in MiB/s; leave it empty to remove it. Use it to let a large package load slowly in the background while the rest of the queue runs at full speed.

The package limit is the narrowest limit there is. The global limit, the one set by hand and the active profile's limits still apply, and the strictest wins; the other packages are not touched. A change reaches the package's running transfers at once, and the limit survives a restart and every profile switch. The REST API offers it as GET|PUT /api/v1/packages/{id}/speed-limit, the MCP server as get_package_speed_limit and set_package_speed_limit.

A torrent cannot be limited on its own: the torrent engine takes a torrent's rates only when it adds the torrent, and cannot change them later. The field is therefore disabled for a package that holds a torrent, and the torrent capabilities report per_torrent_limits: false.

Uploads have a limit of their own; they never count against a download limit. Two values set it:

• the active profile's Upload limit,
• the Upload limit set by hand under Settings → Bandwidth → Status & limits, which survives every profile switch.

The stricter of the two wins; both are unlimited by default. The limit applies to every upload: torrent seeding, object storage uploads, the rclone step and upload destination plugins. The status card shows the Strictest upload limit beside the download one.

Object storage uploads and upload destination plugins follow a profile switch while they run; object storage holds a part back until the limit has released it, so the rate holds on average across the upload. rclone is given the rate in force when it starts and keeps it for that run; a switch reaches its next run.

Transport	Enforcement
HTTP, Usenet	Paced in-band
Torrent	The session takes the stricter of profile and setting; seeding the stricter of the upload limit and the torrent setting
Object storage uploads, upload destination plugins	Paced in-band, following a profile switch
rclone upload	Given --bwlimit for the whole run
yt-dlp, gallery-dl	Given --limit-rate for the whole job
streamlink	Unenforceable — reported as such in GET /api/v1/bandwidth/capabilities

Windows are local times in a configurable IANA time zone and may wrap past midnight.

Duplicate on a window adds a copy right below it, stored with the schedule; Duplicate on a profile makes a copy and opens it in the form.

Overlaps resolve by an explicit priority, then by the later start. A daylight-saving change neither skips a switch nor invents a second one.

The time zone is picked from a searchable list; the default is Europe/Berlin.

The card at the top of Settings → Bandwidth says which profile is active and why — Chosen by the schedule, or Switched by hand, until …. To put another profile in front of the schedule, or lift every limit for a while, pick it (or No limits) and how long it holds, then Switch. The Profile select starts at what is in force — the active profile, or No limits when no profile is active — and keeps a choice you have not switched to yet while the card refreshes:

• Until the schedule's next change — fixed when you switch, so editing the schedule afterwards does not move it,
• For 1 hour / For 3 hours,
• Until I switch back.

Back to the schedule ends it early. The switch survives a restart; deleting the profile in force hands back to the schedule as well. Its budget counts while it is active, like any profile's.

The desktop capture agent can switch a profile on for you while a game or another full-screen program runs (game mode), and hands back to the schedule afterwards; it never ends a switch somebody else made.

A profile with Pause downloads switched on (Profiles tab, off by default) is a download window: while it is in force, no download starts. To download only at night — from 22:00, paused at 06:00 — make such a profile and give it a schedule window Mon–Sun 06:00–22:00. Outside that window the schedule's other profiles apply, or none, and the queue runs.

What the pause does to a download depends on whether it can resume:

• Pauses, and goes on when the window ends — HTTP from a server that names the size and serves ranges, Usenet, FTP, SFTP, WebDAV, object storage, and a torrent's download.
• Runs to its end — what would have to start over: a livestream recording, a media download, a gallery, a transfer a plugin carries out, HTTP of unknown size or from a server that ignores ranges. A recording never waits for the window either.
• Not touched — seeding and post-processing go on; uploads keep their own limit.

The schedule's pause is kept apart from yours: its end resumes only what it paused itself, never a download you had paused by hand, and it never lifts a pause of yours.

While it holds, the Downloads toolbar and the transfer rail read Paused by schedule until 22:00. Pointing at it names the profile, and Switch profile leads to the card on Status & limits, which says the same.

Downloading now anyway. Switch by hand to a profile that does not pause downloads, or to No limits — for an hour, say, or until the schedule's next change. That lets everything through. To let one package through and leave the rest waiting, give it Ignore the schedule's pause in its download window.

Two automations at a time do something similar for the whole queue: Pause queue at 06:00 and Start queue at 22:00. That pause is the one Pause all sets: it pauses every download, also one that has to start over afterwards, and has no exception for a single package.

The REST API names the setting pause_downloads on the profile, and GET /api/v1/queue/pause reports the schedule's pause as schedule_pause. MCP shows it in list_bandwidth_profiles, get_bandwidth_status and get_queue_pause.

A package can have a download window of its own, and a category one for its packages — weekly time spans in the schedule's time zone, outside which the package waits, and the exception Ignore the schedule's pause. Set it with Download window… in a package's menu, or in the category editor; the download queue describes both.

A package is never faster than the global limit, the profile's or the one set by hand: its window can bypass the schedule's pause, never the speed ceiling, which protects the line.

Daily and monthly budgets, counted per local calendar period; a restart continues the same period.

An exhausted budget holds back new starts only. Transfers already running finish.

A budget belongs to its profile. Only the profile that is active right now counts: when a profile whose budget is used up stops being active — its time window ends, or it is removed from the schedule — new transfers start again at once, because without a profile no budget applies. Switching to another profile measures that profile's own budget.

A budget running out raises the budget_exhausted notification event, once per profile and period.

Settings → Unattended operation. Quiet hours postpone only the configured work: PAR2 repair, unpacking, uploads and notification grouping. They never touch downloads.

Notifications held during quiet hours arrive at their end as one summary per target, and the browser tab and the capture agent stay silent until then as well; see Notifications.

A job already running is not interrupted; only the next one waits.

Settings → Unattended operation. A queue completion action runs exactly once per drained cycle of work — after post-processing has finished too, not merely after the last byte:

• run a configured script,
• standby,
• shutdown.

Standby and shutdown need an explicit local approval and then count down visibly. The countdown is cancellable — from the interface, or with POST /api/v1/power/cancel — and adding new work or withdrawing the approval calls it off by itself.

A completion script reuses the post-processing sandbox unchanged.

Settings → Unattended operation. Battery and metered operation can hold the queue, with a visible reason. What a platform cannot report is shown as unavailable rather than guessed.

The machine can be kept awake while it is actually working. Standby is held off while a download, a repair or an unpack is running — not while the queue is merely waiting on a schedule or an IP block. The display is a separate switch. The machine is released even if the service is killed outright.

For hosters that limit anonymous downloads per IP address. What a new address takes is specific to your router, so this runs a script you write, in the same sandbox post-processing scripts run in. Configure it under Settings → Network → Reconnect.

Behaviour:

• It acts only while free downloads are actually waiting on such a limit — never on a premium download, which is not subject to it.
• It keeps its distance from the previous attempt.
• By default it waits until nothing is transferring, rather than interrupting a live transfer.
• It runs only inside the times you allow.
• Afterwards the address limits are forgotten and the waiting downloads are queued again.

Off by default. The checks that confirm the new address are the one part of this feature that contacts an outside service; which addresses are asked is configurable. Each check address keeps to the rule for an address you entered — your own network is fine, a link-local address and rDownloader's own ports are not — on every redirect too, and only the first 1 KiB of its answer is read. Switching reconnect on, the script and the check addresses need the administration area (api:admin).

• The download queue — the global speed limit
• Post-processing — what quiet hours postpone
• Hosters and accounts — why reconnect exists
• BitTorrent — the torrent session's own limits
• Desktop capture agent — game mode
• Defaults and limits