An ownership safety fix. No new features.
What changed
Protectarr no longer treats an Arr's "unknown download" queue entry as a full ownership claim.
Protectarr asks each Arr for the downloads it cannot account for as well as the ones it can, because it needs to know whether a queue entry is still sitting there before retrying a removal. Those unknown entries were being read as ownership, which routed the download down the Arr-aware remediation path.
That path cannot work for them. Measured against Sonarr 4.0.20 and Radarr 6.4.4:
- the Arr accepts the removal, and the data really is deleted
- no blocklist entry is created
- no history event is recorded
- no replacement search happens
All three are keyed on a media id the entry does not carry, so there is nothing for the Arr to blocklist against. Protectarr correctly reported the remediation as unverified, which is a terminal state, leaving an entry in the Triage Queue that nothing could ever resolve. The recorded event also said the removal went through the Arr, which it had not.
Two kinds of download look like this:
- one you added to qBittorrent by hand in a category an Arr manages
- one an Arr really did grab, whose series or movie you have since deleted
What this means for you
| Mode | Before | Now |
|---|---|---|
arr_tracked (default)
| deleted the data, no blocklist, permanent unresolvable triage entry | leaves it alone |
allowlist / either
| same broken outcome, recorded as if the Arr handled it | reaped through the category fallback if your configuration calls for it, and recorded as what it is |
The allowlist and either behaviour is equally destructive. The difference is that it is now accurately described: the record says no Arr owned the download, instead of claiming an Arr-aware removal that never happened.
Unchanged
- Downloads an Arr genuinely owns: removal, blocklisting, verification and replacement searches behave exactly as before.
- Orphan handling and its dwell.
- The v0.9.1 protection for downloads whose stored ownership still names an Arr.
Notes
- No configuration changes. No migration. An ownership record written by an older version that names an owner for a download that was never remediable corrects itself the next time the download is seen, and the orphan dwell gates what happens after that.
- A newly observed download with no stored ownership is still subject to a separate first-pass race. That is being worked on and is not fixed here.
- README screenshots still show v0.9.0; patch releases do not regenerate them.
ghcr.io/irnutsmurt/protectarr:0.9.2