FAQ

What does Inspectarr actually do?

It watches your qBittorrent download categories and catches fake or malicious torrents — for example an .exe disguised as a TV episode, or a "movie" that's really a tiny text file pointing at malware. When it finds one, it blocklists the release in Sonarr, Radarr, or Lidarr so the same bad copy is never grabbed again, deletes the torrent and its files, and notifies you. See Detection and Actions.

How is this different from what Sonarr/Radarr already do?

The *arr apps don't inspect the contents of a download for malicious files. They'll happily import a release that passed their naming checks even if it contains an executable payload. Inspectarr fills that gap by looking inside the torrent and acting on what's actually there.

Do I need Prowlarr?

No. Detection, blocklisting, and deletion all work with just qBittorrent and one *arr app. Prowlarr only adds the indexer health scoring and the grab/malicious statistics. See Prowlarr Indexer Scoring.

Why isn't my bad torrent being attributed to an indexer?

Attribution reads the indexer name from the *arr's grab history, which only exists if the *arr grabbed the torrent through its normal search flow. If you added the torrent to qBittorrent by hand or grabbed it directly in Prowlarr's UI, there's no history entry to read — Inspectarr will still detect and delete it, but can't credit an indexer. This is expected. See Prowlarr Indexer Scoring.

My *arr connection tests fine but attribution still doesn't work.

Check whether your *arr uses a base path. If Radarr is served at http://host:7878/radarr, the URL in your config must include /radarr. The connection test can pass without it because the root API responds, but history lookups won't — and attribution depends on history. See Troubleshooting.

How do I test a new rule without deleting anything?

Turn on Dry Run (globally in Settings → General, or with --dry-run on the CLI). The detection logic runs normally but stops before blocklisting or deleting — matches are logged as dry_run events so you can confirm the rule behaves before going live. See Rules.

Will Inspectarr delete good torrents?

Only if a rule matches one. The most common cause of an unexpected deletion is an overly broad rule — a bad_filename_patterns entry of .* matches everything, for instance. Test rules with Dry Run first. Inspectarr never touches torrents in categories no rule watches.

What happens if an *arr is down when a bad torrent is found?

That's controlled by on_arr_failure. With delete (default) the torrent is removed from qBittorrent anyway and the failure is logged. With abort the torrent is left alone and queued for retry. See Detection and Actions.

The scan says it checked 2 torrents but I only have 1.

Older versions counted a torrent once per matching rule, so a torrent caught by two rules on the same category showed as 2 checked. Current versions count unique torrents. If you're seeing this, update to the latest release.

Does Inspectarr support qBittorrent 5.x?

Yes — both 4.x and 5.x are supported, including the changed torrent states and stop/start endpoints in 5.x.

Can I run it without Docker?

Yes. Clone the repo, pip install -r requirements.txt, and run python3 web.py. Dependencies are minimal. See Installation.

Where is my data stored?

In the data/ directory: inspectarr.db (SQLite — processed hashes, retry queue, run history, indexer stats, attribution) and inspectarr.log.json (the event log). Mount data/ as a volume so it survives container recreation.