-
Notifications
You must be signed in to change notification settings - Fork 0
Troubleshooting
A practical guide to the problems people actually hit. Most issues fall into three buckets: connections, detection, and attribution.
The most common cause is a missing base path. If your *arr or Prowlarr is served under a sub-path — http://host:7878/radarr, http://host:9696/prowlarr — that path has to be in the URL you configure. The connection test hits the root API, which often responds either way, so the test passing doesn't prove the path is right. History and indexer queries do need the correct path.
Fix: add the base path to the URL in Settings → Connections (and the Indexers section for Prowlarr), then re-test.
- Confirm the URL and port are reachable from wherever Inspectarr runs (inside the container, if Dockerized —
localhoston the host is notlocalhostin the container). - Confirm the API key is correct.
- For qBittorrent, confirm the Web UI is enabled and the username/password are right.
Work through these:
- Is it in a category a rule watches? A rule only sees torrents in its configured category. A torrent in an unwatched category is ignored.
-
Does the rule's condition actually match? If you're catching by extension, confirm the bad file's extension is in
bad_extensions. Turn onDEBUGlogging (Settings → Advanced) to see per-file evaluation. - Has it already been processed? Once Inspectarr actions a hash it records it and skips it next time. A torrent that was handled won't be touched again.
- Was the file list available? If the torrent hadn't started and had no files yet when the scan ran, there was nothing to evaluate. It'll be checked on the next scan once files appear.
Almost always an overly broad rule. Check your bad_filename_patterns for something like .* (matches everything) and your bad_extensions for an extension that legitimately appears in your downloads — .rar and .zip are the usual culprits, since plenty of legitimate releases ship as archives.
To find out exactly why it went: every catch writes an inspection record with each finding, its severity, and the specific extension or pattern that matched. Filter the log to the ACTION level and look for the inspection_id on the deletion event; every event for that catch shares it.
To stop it happening again, you have three options in increasing strength:
- Fix the rule and validate the correction with Dry Run.
-
Reclassify the extension —
severity_overrides: {".rar": LOW}demotes it without removing the check. -
Open a quarantine band — raise
remediation.remediate_atso lower-severity catches are paused and held for review instead of deleted. See Quarantine & Severity.
Attribution is the part that credits an indexer with a grab or a malicious hit. If the Stats page stays empty or an indexer never gets credited:
Attribution reads the *arr's grab history. A torrent added manually to qBittorrent or grabbed in Prowlarr's UI has no *arr history entry and can't be attributed. This is expected, not a fault.
This is the single most common attribution failure. The history endpoint needs the correct base path even when the connection test passed without it. See the connection section above.
The *arr stores the indexer name with (Prowlarr) appended (e.g. TorrentProject2 (Prowlarr)) while Prowlarr's own list calls it TorrentProject2. Inspectarr normalizes this automatically — but if you've renamed an indexer in Prowlarr so the base names no longer correspond, the match can fail. Keep the Prowlarr indexer name and the synced name aligned.
Stats only count torrents seen after attribution started working. Torrents already in qBittorrent before then won't be counted until they're seen on a scan.
The richest diagnostic is the event log (System → Events, or data/inspectarr.log.json). Set logging.level to DEBUG in Settings → Advanced for verbose per-torrent and per-file detail, then reproduce the issue and read back through the events. Attribution failures are logged at WARNING with an event like grab_attribution_no_match, which includes the indexer name that couldn't be matched and the list of available indexers — usually enough to spot a base-path or naming mismatch immediately.
- Confirm the scheduler is running (Dashboard or Scheduler page) — it starts stopped on a fresh launch unless
scheduler_autostartis on. - Check the service is up:
sudo systemctl status inspectarr, ordocker logs inspectarr. - Confirm
config.yamlis valid — a malformed file will prevent scans. The Raw YAML editor in Settings will surface parse errors.
Quarantine holds are resolved by you, not by a timer, unless you set quarantine_timeout_minutes. If an entry will not clear:
- "Release" reports the client refused to resume. The hold stays deliberately — resolving it would drop the torrent from the queue while leaving it paused. Confirm the torrent still exists in your client.
- The entry says "not paused". The client refused to pause it when it was held, so it kept downloading. The hold is still valid; the torrent just is not stopped.
- The torrent is gone from the client entirely. Release or Delete both detect this and clear the hold, reporting that it was already absent.
That is the default. Both min_severity and remediate_at ship as LOW, which means everything flagged is deleted immediately and the quarantine band is empty. Raise Delete at or above under Settings → Rules to open one.
Usually context size. The scoring prompt is roughly 5,700 tokens at 39 indexers, and a model with a 4k window silently loses the instructions and fabricates scores rather than erroring.
Run Settings → AI → Validate — the context test is sized to your real indexer count and will fail loudly for exactly this reason. See AI & Model Validation.