[BUG] Queue Cleaner does not blocklist release on 'Failed Import', causing re-download loop #19

New Issue

giteasync · 2025-10-09T16:56:30-05:00

giteasync commented

2025-10-09 16:56:30 -05:00

Originally created by @Molier on GitHub.

Before submitting a bug report, I have:

Reviewed the documentation.
Ensured I am using ghcr.io/cleanuparr/cleanuparr docker repository.
Ensured I am using the latest version.
Enabled verbose logging.

What is the behavior?

When the Queue Cleaner module identifies a download that Sonarr/Radarr cannot import (specifically "No files found are eligible for import" due to .iso/.exe files), it successfully removes the download from the download client. However, it does not appear to apply a blocklist to the release within the *arr application.

Immediately after deletion, Cleanuparr triggers a search, and the *arr application proceeds to re-download the exact same problematic release, creating an infinite loop. The Malware Blocker module, when it gets a chance to run, does correctly apply the blocklist. This suggests the blocklisting logic is missing or failing within the Queue Cleaner's "Failed Import" workflow.

What I expected to happen:

The Queue Cleaner, upon removing a failed download, should also add that release to the Sonarr/Radarr blocklist to prevent it from being downloaded again in the subsequent search.

[QueueCleaner] [Sonarr] Item Wednesday S02E05 ... has failed import status...
{"Title":"Wednesday...","Messages":["No files found are eligible for import in ...Wednesday.iso"]}
[QueueCleaner] [Sonarr] item marked for removal | Wednesday S02E05...
queue item deleted with reason AllFilesSkippedByQBit | http://sonarr:8989/ | Wednesday S02E05...
episodes search triggered | http://sonarr:8989/ | [Wednesday S02E05]

Sonarr Log (immediately following the Cleanuparr search trigger):

[Info] ReleaseSearchService: Searching indexers for [Wednesday : S02E05]. 13 active indexers
[Info] DownloadDecisionMaker: Processing 75 releases
[Info] DownloadService: Report sent to qBittorrent. Indexer TheRARBG (Prowlarr). Wednesday S02E05 1080p WEB H264-SuccessfulCrab

### Which operating system do you use?

Linux

### What type of deployment do you use?

Docker container

### Relevant log output

```shell

Anything else?

this should perhaps be a feature request , for a boolean option to add to blocklist when queue remover hits import strikes: Currently, when the Queue Cleaner removes a download due to a "Failed Import" (e.g., the torrent only contains an .iso), it does not blocklist the release in Sonarr/Radarr. The subsequent search triggered by Cleanuparr often re-downloads the exact same problematic release, causing a loop. The Malware Blocker does correctly blocklist releases, but the Queue Cleaner often acts first on the "Failed Import" symptom. The current workaround is to add the import error message to the Queue Cleaner's "Ignored Patterns" to let the Malware Blocker handle it, but this is not immediately intuitive.

but i wanted to open the question since i was very confused by default behaviour

Originally created by @Molier on GitHub. ### Before submitting a bug report, I have: - [x] Reviewed the documentation. - [x] Ensured I am using ghcr.io/cleanuparr/cleanuparr docker repository. - [x] Ensured I am using the latest version. - [x] Enabled verbose logging. ### What is the behavior? When the Queue Cleaner module identifies a download that Sonarr/Radarr cannot import (specifically "No files found are eligible for import" due to .iso/.exe files), it successfully removes the download from the download client. However, it does not appear to apply a blocklist to the release within the *arr application. Immediately after deletion, Cleanuparr triggers a search, and the *arr application proceeds to re-download the exact same problematic release, creating an infinite loop. The Malware Blocker module, when it gets a chance to run, does correctly apply the blocklist. This suggests the blocklisting logic is missing or failing within the Queue Cleaner's "Failed Import" workflow. ## What I expected to happen: The Queue Cleaner, upon removing a failed download, should also add that release to the Sonarr/Radarr blocklist to prevent it from being downloaded again in the subsequent search. ``` [QueueCleaner] [Sonarr] Item Wednesday S02E05 ... has failed import status... {"Title":"Wednesday...","Messages":["No files found are eligible for import in ...Wednesday.iso"]} [QueueCleaner] [Sonarr] item marked for removal | Wednesday S02E05... queue item deleted with reason AllFilesSkippedByQBit | http://sonarr:8989/ | Wednesday S02E05... episodes search triggered | http://sonarr:8989/ | [Wednesday S02E05] ``` *Sonarr Log (immediately following the Cleanuparr search trigger):* ```log [Info] ReleaseSearchService: Searching indexers for [Wednesday : S02E05]. 13 active indexers [Info] DownloadDecisionMaker: Processing 75 releases [Info] DownloadService: Report sent to qBittorrent. Indexer TheRARBG (Prowlarr). Wednesday S02E05 1080p WEB H264-SuccessfulCrab ### Which operating system do you use? Linux ### What type of deployment do you use? Docker container ### Relevant log output ```shell ``` ### Anything else? this should perhaps be a feature request , for a boolean option to add to blocklist when queue remover hits import strikes: Currently, when the Queue Cleaner removes a download due to a "Failed Import" (e.g., the torrent only contains an .iso), it does not blocklist the release in Sonarr/Radarr. The subsequent search triggered by Cleanuparr often re-downloads the exact same problematic release, causing a loop. The Malware Blocker does correctly blocklist releases, but the Queue Cleaner often acts first on the "Failed Import" symptom. The current workaround is to add the import error message to the Queue Cleaner's "Ignored Patterns" to let the Malware Blocker handle it, but this is not immediately intuitive. but i wanted to open the question since i was very confused by default behaviour

giteasync added the

bug

label 2025-10-09 16:56:30 -05:00

giteasync closed this issue

2025-10-09 16:56:31 -05:00

giteasync commented

2025-10-09 16:56:31 -05:00

@Flaminel commented on GitHub:

No problem! If they had different hashes, then yes, they would be considered unique even though it's the exact same content inside them. Thank you for the update!

@Flaminel commented on GitHub: No problem! If they had different hashes, then yes, they would be considered unique even though it's the exact same content inside them. Thank you for the update!

giteasync commented

2025-10-09 16:56:31 -05:00

@Molier commented on GitHub:

i cannot verify perfectly since sonarr for some reason purged the history of the file. but i have this screenshot from when i was diagnosing, and if i recall , I figured out that all the releases were 'unique'.
As in, they were all brought in from separate trackers that i had set up i think and that's why it kept re-grabbing them perhaps? and every time it was malware so it got a strike and removed but only got banned after 3 strikes or something? and then it tried again, different tracker but actually same malware release perhaps.

But either way I have not seen the behavior reproduced so as far as I can see this can be closed :) . thank you for the follow up.

@Molier commented on GitHub: i cannot verify perfectly since sonarr for some reason purged the history of the file. but i have this screenshot from when i was diagnosing, and if i recall , I figured out that all the releases were 'unique'. As in, they were all brought in from separate trackers that i had set up i think and that's why it kept re-grabbing them perhaps? and every time it was malware so it got a strike and removed but only got banned after 3 strikes or something? and then it tried again, different tracker but actually same malware release perhaps. But either way I have not seen the behavior reproduced so as far as I can see this can be closed :) . thank you for the follow up. <img width="3646" height="1573" alt="Image" src="https://github.com/user-attachments/assets/adba658a-bd88-4a56-b1ae-bd8cfe398a82" />

giteasync commented

2025-10-09 16:56:32 -05:00

@magrhino commented on GitHub:

I believe I am having the same issue as well. Cleanuparr repeatedly deleted a private torrent on import from my seedbox due to a "failed import". I did have the box checked to ignore private torrents. It did not blacklist the torrent and continued to retry.

@magrhino commented on GitHub: I believe I am having the same issue as well. Cleanuparr repeatedly deleted a private torrent on import from my seedbox due to a "failed import". I did have the box checked to ignore private torrents. It did not blacklist the torrent and continued to retry. ![image](https://github.com/user-attachments/assets/8f9654b9-da23-4a83-a9bf-826af8a8473e)

giteasync commented

2025-10-09 16:56:32 -05:00

@Flaminel commented on GitHub:

@Molier ?

@Flaminel commented on GitHub: @Molier ?

giteasync commented

2025-10-09 16:56:32 -05:00

@Flaminel commented on GitHub:

Both Malware Blocker and Queue Cleaner use the same way to remove and block items from the queues and, as you can see here, items are always blocklisted. Given that there's no difference between them, are you 100% sure Malware Blocker actually did anything different?

While it's pretty rare, it is possible that Sonarr does not blocklist some of the items, but I have no idea why and I can't fix that. The API call to do it should be correct.

@Flaminel commented on GitHub: Both `Malware Blocker` and `Queue Cleaner` use the same way to remove and block items from the queues and, as you can see [here](https://github.com/Cleanuparr/Cleanuparr/blob/main/code/backend/Cleanuparr.Infrastructure/Features/Arr/SonarrClient.cs#L45), items are always blocklisted. Given that there's no difference between them, are you 100% sure `Malware Blocker` actually did anything different? While it's pretty rare, it is possible that Sonarr does not blocklist some of the items, but I have no idea why and I can't fix that. The API call to do it should be correct.

giteasync commented

2025-10-09 16:56:33 -05:00

@Flaminel commented on GitHub:

@magrhino there's no issue with Cleanuparr here.

For blacklisting: make sure you have blacklisting enabled in your apps, as explained in #314. Also to note that the same release may have a different hash on different trackers, so blocking one of them is not going to block all of them.
For private torrents: make sure you have your download client configured in Cleanuparr's settings, otherwise it can not know what is private and what is public.

@Flaminel commented on GitHub: @magrhino there's no issue with Cleanuparr here. 1. For blacklisting: make sure you have blacklisting enabled in your apps, as explained in #314. Also to note that the same release may have a different hash on different trackers, so blocking one of them is not going to block all of them. 2. For private torrents: make sure you have your download client configured in Cleanuparr's settings, otherwise it can not know what is private and what is public.

giteasync referenced this issue

2025-10-09 17:00:52 -05:00

[PR #19] [MERGED] upgraded to .NET 9 #301

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/Cleanuparr-Cleanuparr#19