starred/Radarr

Fork 0

mirror of https://github.com/Radarr/Radarr.git synced 2026-03-02 22:57:34 -05:00

[FEAT]: Download Client Tag/Category matching should be relaxed for detection of completion #6064

New issue

Open

opened 2026-02-19 23:02:12 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-19 23:02:12 -05:00

Owner

Originally created by @nayfield on GitHub (Sep 18, 2021).

Is there an existing issue for this?

I have searched the existing issues

(This use case is using rutorrent as download client).

Background: It is quite possible - that when Radarr makes a decision to Grab a download, the configured download client already has a copy. (E.g. autodl running every minute has already selected the item, before Radarr runs every 60 minutes).

When the previously downloaded item's tag matches the Radarr configured download client tag, it appears that Radarr will treat this like a download. (including when the existing item and Radarr's tag are blank).

However, when the tags do not match - e.g. the existing item is tagged 'earlybird' and Radarr's tag is blank, or anything that differs ('radarr-downloaded') ... the download client never recognizes the download as completing.

To test:

Download a torrent "a" from your indexer, and leave it untagged
With no tag configured on download client, cause Radarr to download the same torrent
At step 2, the item is downloaded and linked by radarr.
Download torrent "b" from indexer and tag it as 'alreadythere'
Still with no tag configured on download client, cause Radarr to download that torrent
At step 4, we do not get completion of the download.
Reconfigure download client to use tag 'radarr-initiated'
Download torrent 'c' from indexer, do not tag
Cause Radarr to grab torrent. This will never finish and move to Download event.
Retag torrent 'c' as 'earlybird'. Still no download event
retag torrent 'c' as 'radarr-initiated'. Within a few minutes, the download event will happen.

See below for preferred solution

Describe the solution you'd like

We can expect that hashes (radarr_download_id env var) are unique enough for our purposes...
Thus, if we do a Grab event to a download client, and on subsequent query it sees a completed copy of that hash ...
We should assume that is the intended payload and move to the download step, regardless of tag.

My experience is with rtorrent, but I'd expect most clients do not change tags on an existing torrent when a Grab event happens.

Thus - I feel tags should be ignored when querying a download client for grab completion. If that breaks some other use case, I'm fine with having an option in download client configuration "strict tag matching for downloads" or "ignore client tag as long as hash matches".

Describe alternatives you've considered

I believe I can hack the behavior I want using custom scripts, if must:

if radarr_eventtype == Grab:
sleep for a few seconds
if rtorrent has that hash (radarr_download_id):
if it's not tagged the way radarr wants it, change tag to be so.

This will ensure that Download events are triggered for Grabs of pre-existing content - but at the expense of removing the original tag.

Anything else?

No ... Since a torrent hash collision is very unlikely - there is little value in filtering hashes based on how they are tagged.

AB#1593

Originally created by @nayfield on GitHub (Sep 18, 2021). ### Is there an existing issue for this? - [X] I have searched the existing issues ### Is your feature request related to a problem? Please describe (This use case is using rutorrent as download client). Background: It is quite possible - that when Radarr makes a decision to Grab a download, the configured download client already has a copy. (E.g. autodl running every minute has already selected the item, before Radarr runs every 60 minutes). When the previously downloaded item's tag matches the Radarr configured download client tag, it appears that Radarr will treat this like a download. (including when the existing item and Radarr's tag are blank). However, when the tags do not match - e.g. the existing item is tagged 'earlybird' and Radarr's tag is blank, or anything that differs ('radarr-downloaded') ... the download client never recognizes the download as completing. To test: 1. Download a torrent "a" from your indexer, and leave it untagged 2. With no tag configured on download client, cause Radarr to download the same torrent At step 2, the item is downloaded and linked by radarr. 3. Download torrent "b" from indexer and tag it as 'alreadythere' 4. Still with no tag configured on download client, cause Radarr to download that torrent At step 4, we do not get completion of the download. 5. Reconfigure download client to use tag 'radarr-initiated' 6. Download torrent 'c' from indexer, do not tag 7. Cause Radarr to grab torrent. This will never finish and move to Download event. 8. Retag torrent 'c' as 'earlybird'. Still no download event 9. retag torrent 'c' as 'radarr-initiated'. Within a few minutes, the download event will happen. See below for preferred solution ### Describe the solution you'd like - We can expect that hashes (radarr_download_id env var) are unique enough for our purposes... - Thus, if we do a Grab event to a download client, and on subsequent query it sees a completed copy of that hash ... - We should assume that is the intended payload and move to the download step, regardless of tag. My experience is with rtorrent, but I'd expect most clients do not change tags on an existing torrent when a Grab event happens. Thus - I feel tags should be ignored when querying a download client for grab completion. If that breaks some other use case, I'm fine with having an option in download client configuration "strict tag matching for downloads" or "ignore client tag as long as hash matches". ### Describe alternatives you've considered I believe I can hack the behavior I want using custom scripts, if must: if radarr_eventtype == Grab: sleep for a few seconds if rtorrent has that hash (radarr_download_id): if it's not tagged the way radarr wants it, change tag to be so. This will ensure that Download events are triggered for Grabs of pre-existing content - but at the expense of removing the original tag. ### Anything else? No ... Since a torrent hash collision is very unlikely - there is little value in filtering hashes based on how they are tagged. [AB#1593](https://dev.azure.com/Servarr/7ab38f4e-5a57-4d70-84f4-94dd9bc5d6df/_workitems/edit/1593)

deekerman added the

Type: Feature Request

Area: Download Clients

Status: Unlikely

labels

2026-02-19 23:02:12 -05:00

deekerman commented

2026-02-19 23:02:13 -05:00

Author

Owner

@ta264 commented on GitHub (Sep 18, 2021):

I think this is unlikely to happen - the point of the download client categories is to stop radarr looking at stuff you don't want it to. I don't think we'd want to implement an option - in my view it's too niche. Let's see what other members of the dev team think.

@ta264 commented on GitHub (Sep 18, 2021): I think this is unlikely to happen - the point of the download client categories is to stop radarr looking at stuff you don't want it to. I don't think we'd want to implement an option - in my view it's too niche. Let's see what other members of the dev team think.

deekerman commented

2026-02-19 23:02:13 -05:00

Author

Owner

@austinwbest commented on GitHub (Sep 18, 2021):

Going to agree, labels stay as is would be my thought on it.

@austinwbest commented on GitHub (Sep 18, 2021): Going to agree, labels stay as is would be my thought on it.

deekerman commented

2026-02-19 23:02:13 -05:00

Author

Owner

@nayfield commented on GitHub (Sep 21, 2021):

the downside of not implementing anything:

On Grab - if Radarr submits an ask for a torrent that is already downloaded with a different tag, nothing will happen. Radarr will wait indefinitely for torrent with to show up.

You need to manually re-tag the already downloaded item, or delete it - and then reset radarr so it will grab again (doubling downloads).

AFAICT - if the download client already has a given torrent hash with a different tag, it will break radarr's downloading of that movie until manual intervention occurs.

@nayfield commented on GitHub (Sep 21, 2021): the downside of not implementing anything: On Grab - if Radarr submits an ask for a torrent that is already downloaded with a different tag, nothing will happen. Radarr will wait indefinitely for torrent <hash> with <tag radarr> to show up. You need to manually re-tag the already downloaded item, or delete it - and then reset radarr so it will grab again (doubling downloads). AFAICT - if the download client already has a given torrent hash with a different tag, it will break radarr's downloading of that movie until manual intervention occurs.