File Detection 22 extensions monitored

Monitored Extensions

A download is flagged for removal when its file list contains any of these. Separate with commas or newlines; a leading dot is added if you leave it off.

Recommended. Much faster on large libraries, and a fake that has already finished is past the point of catching.

How this works

Public trackers seed video-sized decoys named like Show.S01E01.1080p….exe. qBittorrent learns a torrent's file list from its metadata within seconds of adding it, long before any content arrives, so an extension match costs no bandwidth and answers almost immediately.

Skipping finished torrents leaves Sonarr/Radarr's own "Fail Downloads" as the backstop for anything that completes between two scans.

Lure Filenames

Matched as substrings of the filename. Separate with commas or newlines.

How this works

Flags a download when a text-like companion file (readme / nfo / url) is named like a fake's instructions, for example password.txt or how to download.html.

Only those note-style files are checked, which is what stops a false positive: a real release titled Password.mkv is never flagged, because a video file is not a note.

Archive Detection - advanced, opt-in Disabled

Flags a download that contains only archives (RAR/ZIP/…) with no real media file. Legit releases are sometimes packed in RARs - especially on private trackers - so this is off by default and only applies to the indexers you list below. Leave the list empty to disable.

Loading indexers from your apps…

With none selected this rule never fires, whatever the checkbox above says.

How this works

Only *arr-tracked downloads are eligible, because that is where the indexer name comes from and where "what counts as media" is knowable. Hand-added torrents are never touched by this rule.

A torrent is only archives-only if Protectarr finds no media file at all in the list. One real video alongside the RARs and the rule does not fire.

Remediation Policy Arr-tracked only

Current policy
Mode
Live, fakes are removed for real
Scope
Arr-tracked only
Category fallback
Not used in this mode. Your selection is kept.
Orphan handling
Not used in this mode. Only an application can act.
Replacement search
After a verified removal, once the release is out
Air-date constraint
As soon as it has aired

Reaping Rules

Currently: Live - fakes will be removed for real.

Loading categories from qBittorrent…

Loading tags from qBittorrent…

A torrent matches the allowlist if its category or any of its tags is selected.

How this works

either covers a gap the others leave open. When an application fails a release it drops it from its queue but the torrent can keep downloading in qBittorrent, owned by nobody - arr_tracked will not touch it and the payload finishes anyway. In either mode a tracked torrent is still handed back to its application (which blocklists it and decides about requeueing), and an orphan in an allowed category is deleted from qBittorrent directly.

Handing a download back to its application is always preferred, because that is the path that blocklists the release so the same fake is not grabbed again. Deleting from qBittorrent can only stop this copy.

Only once the episode or movie has actually aired or been released, and only after the removal has been verified. Unchecked means blocklist only, never search.

Ownership & Orphan Handling

How long a previously application-owned download must remain continuously confirmed absent before category fallback may act on it.

How this works

Protectarr remembers which application owned each download. When one disappears from that application's queue it becomes an orphan, and only then can the category fallback act on it.

Confirmed absence means Protectarr successfully read that application's queue and the download was not in it. A queue it could not reach does not count and does not advance the clock - an application that is down or restarting never ages its own downloads into orphans. If the download reappears the clock resets to zero.

A download that has finished is never an orphan either: succeeding also removes it from the queue, which is the application importing it rather than abandoning it.

Advanced tuning

How long past the air or release time to wait before a replacement search is allowed. Web releases often land a little after the broadcast slot. Has no effect unless the replacement search above is on.

Content Probe - advanced, opt-in Disabled

Catches a payload wearing a real .mkv or .mp4 extension by reading the first piece of one file. A file that cannot be read, cannot be recognised, or runs out of budget produces no finding - never a removal.

How this works

Everything else Protectarr does reads the torrent's file list, which is why it costs no bandwidth and answers in seconds. That cannot catch a payload wearing a real .mkv or .mp4 extension, because nothing in the metadata is lying. The probe downloads the first piece of one file - a few MB out of many GB - and checks the bytes really are the format the name claims.

It only runs on torrents the fast checks had nothing to say about, and only on torrents your reaping rules would let Protectarr act on.

A scan that has a fake queued for removal reaps it first and probes on the next pass, so probing never delays a removal the fast checks already decided on.

Path Mapping

No mappings, which is correct if Protectarr already sees the downloads at the same path qBittorrent reports. Add one only if the two differ.

How this works

Protectarr has to be able to read the files qBittorrent is writing, so mount the download directory into Protectarr as well. If it lands at the same path qBittorrent reports, you are done and need nothing here.

Add a mapping only when the two see the same folder at different paths: it translates one into the other. Note the path to match is the one qBittorrent reports, which on a NAS is often not the host path - a share at /volume2/Media/torrents may be /Media/torrents to qBittorrent. The Test button prints both paths for a live download, so you can check rather than guess.

Advanced tuning

Reading a piece the torrent already happens to have is free, and always allowed. Fetching one on purpose means briefly raising one file's priority above the torrent's other files and turning on sequential download - always restored afterwards, and restored on the next start if Protectarr is killed mid-probe. Nothing is switched off, so the torrent's size and progress never change. These limits bound what that is allowed to cost.

Uncheck to only ever read what is already downloaded. Everything below only bounds the steered half, so it does nothing while this is off.

Stop steering early when Protectarr sees no progress toward the target file's opening piece for this long, and put the settings back. This watches that one piece, not the file's overall progress: a torrent can be pulling bytes for the file at full speed while the piece we actually need is never requested, which is measured behaviour rather than a hypothetical. Without this the probe would hold the boost for its whole budget while accomplishing nothing.

Steering only influences which piece qBittorrent picks next; it cannot recall one already in flight. On a torrent crawling from one seed the piece may be twenty minutes away, so the budget is better not spent. Fakes are heavily seeded by design - the attacker wants downloads - so the torrents that matter are the ones this works best on.