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?

It only acts on rule matches, so the honest answer depends on your rules. Two things reduce the risk:

• Dry Run shows what would happen without doing it. Always start here.
• Quarantine gives you a middle ground. Every catch is graded by severity, and you can choose a threshold below which catches are paused and held for review instead of deleted — so an .exe is removed on sight while a .rar-only match waits for you to look at it.

By default there is no quarantine band and everything flagged is deleted immediately, which is the behaviour Inspectarr has always had. Opening a review band is opt-in.

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.

Do I need Ollama or any AI for this?

No. Detection, severity grading, quarantine, and remediation are entirely deterministic — no model is ever consulted. Ollama is optional and only affects indexer scoring and notification summaries. Leave the Ollama URL blank and everything else works unchanged.

How do I know a model actually works before relying on it?

Validate it. Settings → AI → Validate runs three tests against a candidate model, sized to your real indexer count, and a model that fails cannot be applied by accident. See AI & Model Validation.