external tools

External tools

rDownloader runs a handful of programs it does not ship. yt-dlp, gallery-dl, streamlink, ffmpeg and ffprobe do the work for media, galleries and recordings; unrar, 7z and rclone do the work after it; apprise delivers Apprise notifications.

Their versions move on their own schedule, so a binary on disk can be too old for what rDownloader asks of it. The versions are therefore checked.

Where a tool is looked up

A program path set under Settings → Tools → Paths (Custom paths) comes first; without one, in this order:

1. The configured vendor directory (Settings → Tools → Paths).
2. vendor/ next to the executable.
3. vendor/ inside the data directory.
4. PATH.

Dropping the binaries into one folder is enough — no system-wide installation, no per-tool paths. Settings → Tools → Status and rdownloader doctor show for each tool where it was found, which version it reports and its verdict.

yt-dlp needs ffprobe next to ffmpeg to merge video and audio. Installing one without the other is the most common half-working setup.

On Windows, 7z.exe needs 7z.dll beside it. It loads every archive format from that DLL and opens no archive without it. The Windows package ships both, from the same official 7-Zip installer; a 7z.exe you drop into the vendor folder yourself needs its 7z.dll next to it.

The Linux and Windows packages carry the license texts of the tools they ship under vendor/licenses/; Settings → About rDownloader → Licenses lists them too.

The Docker image ships ffmpeg, yt-dlp, streamlink, gallery-dl, 7-Zip with its RAR codec, par2 and Apprise at pinned versions, so RAR and RAR5 archives unpack there too. unrar stays out: 7-Zip covers RAR5, and Debian's unrar-free cannot read it. A newer binary can still be dropped into /config/vendor. The licences are listed on Docker and NAS.

The four verdicts

Verdict	Meaning	Effect
supported	At or above the floor and not on a known-bad list	Nothing
too_old	Below the floor this build is tested against	Blocks the named capabilities
known_bad	A specific release listed as broken	Blocks the named capabilities
unknown	The version could not be read, or no rule covers the tool	Never blocks

An unreadable version is not a fault: FFmpeg git builds print N-113522-g8b0a3d5c, which carries no number to compare and is usually newer than every release. So unknown warns and gates nothing.

What a verdict costs

A rule names the capabilities it affects, and only those are blocked. Nothing here can refuse work in general: a yt-dlp below the floor stops media downloads while HTTP transfers, the Usenet queue, torrents and everything else keep running.

Capability	What stops	Tools it depends on
media_download	Probing and downloading media	yt-dlp
media_merge	Merging separate video and audio streams	ffmpeg and ffprobe
audio_extraction	Converting to MP3	ffmpeg and ffprobe
gallery_download	Downloading an image gallery	gallery-dl
stream_recording	Recording a live stream	streamlink

A blocked job fails with media.tool_incompatible, naming the tool, its version, the minimum and the capability that was lost.

The floors

Each floor is the oldest version rDownloader accepts: below it a tool lacks something rDownloader relies on or has a known security problem. Which versions are actually exercised is in the support matrix.

Tool	Minimum	Known bad	Capabilities gated
yt-dlp	2023.01.06	—	media_download
gallery-dl	1.25.0	—	gallery_download
streamlink	8.2.0	—	stream_recording
ffmpeg	4.4	—	media_merge, audio_extraction
ffprobe	4.4	—	media_merge, audio_extraction

rclone and apprise carry no rule; their own failures are reported by the tools themselves. PAR2 repair runs inside rDownloader, with no binary to check.

No release is listed as known bad. Such a listing would arrive with the signed manifest (see Overriding a rule). Rules that cannot be read fall back to the ones built into the release.

The archive tools' security floor

Tool	Minimum	Why
unrar (also the full rar)	6.12	Older versions let a link inside the archive write outside the destination (CVE-2022-30333)
7z (7-Zip, p7zip)	25.00	The same through symbolic links (CVE-2025-11001, CVE-2025-11002); p7zip 16.02, the last p7zip, is far below

These two floors are about safety, not features, and behave differently from the table above:

• A tool below the floor is not started. The archive set fails with extract.tool_outdated, naming the tool, the version found and the minimum, and the RAR integrity test is skipped. Settings → Tools → Status and rdownloader doctor show the tool as too_old with its floor.
• Nothing lifts them. They are part of the program: the signed manifest cannot change them and tool_compatibility_overrides cannot name either tool.
• An unreadable version still extracts. A renamed or wrapped binary whose version cannot be read is unknown like everywhere else here: extraction runs and a warning goes to the log.
• The version is read from the first line the tool prints when started without arguments (UNRAR 7.01 freeware, 7-Zip (z) 25.01 (x64)).

A tool below its floor is replaced, not configured around: point External RAR tool under Settings → Tools → Paths at a current unrar, drop a current 7-Zip into the vendor folder, or remove the old binary from PATH. An unrar older than 6.10 whose version could not be read is still refused when it runs, with extract.tool_too_old, because it does not know the -op switch the destination is passed in.

Managed tools

Optional, and off by default. rDownloader can download, verify, activate and roll back yt-dlp, gallery-dl, streamlink, ffmpeg and ffprobe itself. Switch it on under Settings → Tools → Managed tools → Manage tools automatically.

How it works:

• Every build comes from a signed manifest with its SHA-256, checked before it is activated.
• It lands in <data>/tools/<name>/<version>/.
• Activating one takes effect for the next job; a download already running keeps the version it started with.
• A tool path you configured yourself still wins over anything managed.
• Rollback re-points at a version already in the store.
• An install from an archive checks that the program is there under the name this platform looks for — ffmpeg.exe on Windows, ffmpeg elsewhere. An archive that delivers it under another platform's name is refused — … could not be installed, naming the missing file — and nothing is activated.

What the manifest covers

Tool	Platforms
yt-dlp	Linux and Windows, x86-64 and ARM64
ffmpeg, ffprobe	Linux and Windows, x86-64

The version of each is the one the signed manifest names; rdownloader doctor shows the one in use.

macOS has no managed versions. Every tool there resolves through the vendor folders or PATH.

FFmpeg comes from BtbN's builds — a third party, because the FFmpeg project publishes no binaries itself; FFmpeg's own download page points to them. They are pinned by hash to the last build of a month, which BtbN keeps for two years (its daily builds disappear after 14 days), and a weekly check makes sure every download the manifest names still answers.

What is not managed, and why

The manifest offers no build of gallery-dl or streamlink, so they resolve through the vendor folders and PATH; both are fully supported when installed that way.

• gallery-dl publishes to PyPI, not as per-platform binaries to pin a hash against.
• Streamlink publishes no standalone Linux binary, and its Windows bundle is a complete Python runtime.

Overriding a rule

The rules travel in the same signed manifest as the builds, so a rule can be corrected without a new release; on any error the rules built into the release apply. The manifest URL is a setting: empty means the built-in manifest, which needs no network.

When a verdict is wrong for your installation, Settings → Tools → Managed tools → Override compatibility rules takes the tools whose verdict should be reported but not enforced. The warning and the badge stay; only the block goes, and every skipped block is written to the log. A tool with no rule behind it is refused when the settings are saved.

Checking what you have

rdownloader doctor

names each tool, where it was found, its version, its verdict and the upgrade path when there is one. The same information is on Settings → Tools → Status and in a diagnostic bundle's system-checks.json.

What has actually been verified

A minimum is not a guarantee that a tool has been run: how each tool is tested, and what is not tested yet, is on the support matrix.

Related pages

• Video and audio downloads
• Image galleries · Livestream recording
• Post-processing — unrar, 7z, rclone
• Diagnostics and maintenance
• Docker and NAS
• Support matrix