Questions people ask

Why is there no web UI?

Because there is nothing to click. plungarr applies a policy you set once: for each reason a download can be stuck, replace it, discard it, or leave it and tell you. The log shows what it did, and the digests tell you what still needs a human, with the setting that would auto-clear it. A UI would be a page of the same settings plus a button for an action the service already takes. If you want buttons for one-off actions, Cleanuparr has them.

Isn't this just Cleanuparr or Decluttarr?

They clean the queue. plungarr also finishes the import when the only problem was a technicality, knows the difference between “not an upgrade” and “archive not extracted”, and was built around SABnzbd. They are well ahead on torrents and support more arrs. The comparison is honest about both directions.

Shouldn't Sonarr do this itself?

Probably, for some of it. Sonarr deliberately stops at “manual import required” when it cannot be certain, and that caution is right for the default. plungarr adds the checks a careful human would make before clicking import, and lets you decide the policy for the rest. If Sonarr grows those checks, plungarr shrinks.

What can go wrong?

plungarr can remove a download from your queue and download client, and blocklist a release. It cannot delete a library file, import a file into the wrong series or movie, or act on a state it does not recognise. Run DRY_RUN=true for a day to see every action it would take, and set any *_ACTION to notify to take a reason out of its hands.

I use qBittorrent, not SABnzbd. Is it useful?

Yes for the queue side: import handling and the per-reason policies work through the arr's own API regardless of client. The stall watcher is SABnzbd-only, so a stalled torrent is not something plungarr sees. Leave SABNZBD_URL empty and that part stays off.

I run two Sonarrs, one for anime.

Add SONARR_2_URL, SONARR_2_API_KEY, and optionally SONARR_2_NAME=anime. Up to nine of each app, same pattern for Radarr. If both share a SABnzbd, configure both in the one container so the stall watcher knows every owner. Details.

Which notification services are actually tested?

ntfy, against a live receiver. The others are implemented from each service's published API and covered by unit tests, but had not been run against a real Discord, Slack, Gotify or Apprise at the time of writing. The notifications page keeps this status current. If one misbehaves, the log line NOTIFY-ERROR has what is needed to fix it.

Was AI used to build this?

Yes. It runs on the author's own library, every action has a regression test that runs before any image is published, and the safety rules on the home page are enforced in tests, not just described. The source is a single readable file if you would rather check for yourself.

It keeps notifying me about a sample that is a real episode.

Sonarr's sample detector trips on short-form shows. plungarr defaults SAMPLE_ACTION to notify for exactly that reason. Import the episode by hand in Sonarr, or set SAMPLE_ACTION=discard if you would rather those releases were dropped automatically.

The library review flagged a lot of files.

By default it reports only the actionable classes: an MKV with no media info, a tiny file with no metadata, or a very low bitrate for its length. Small readable files and unscanned containers such as .avi or .iso are opt-in via CORRUPT_REPORT_CLASSES. Each file is reported once, then again only if it changes. Nothing is ever deleted.

It does not handle a block I see all the time.

Open an issue with the exact message text from the queue. New reasons are added as settings with the same replace, discard, or notify choice.