[BUG] Cleanuparr keeps crashing Deluge 2.2.0 - &#34;invalid torrent handle used&#34; #23

@Flaminel commented on GitHub:

If you're only using Malware Blocker, then Cleanuparr does not send a command to Deluge at all. Cleanuparr sends a remove-from-the-queue command to Sonarr, which then sends a command to Deluge to remove the download.

Also it looks like invalid torrent handle might occur when the download has already been removed (I'm not sure tho).

@Flaminel commented on GitHub: If you're only using Malware Blocker, then Cleanuparr does not send a command to Deluge at all. Cleanuparr sends a remove-from-the-queue command to Sonarr, which then sends a command to Deluge to remove the download. Also it looks like `invalid torrent handle` might occur when the download has already been removed (I'm not sure tho).

giteasync commented

@Flaminel commented on GitHub:

There is no other careful or slow method of removing stuff. Cleanuparr sends a command to Deluge to remove a torrent + data and Deluge handles everything. Also there is no difference in communicating with Deluge since v1, so this process behaves exactly the same as before.

@Flaminel commented on GitHub: There is no other careful or slow method of removing stuff. Cleanuparr sends a command to Deluge to remove a torrent + data and Deluge handles everything. Also there is no difference in communicating with Deluge since v1, so this process behaves exactly the same as before.

giteasync commented

@bentrop commented on GitHub:

Somehow, somewhere, my workflow doesn't flow reliably. Bringing everything back online instantly loaded some brand-new malware, Cleanuparr marked it as failed in Sonarr ... but that's it, it just happily kept downloading. At least, nothing triggered any lock-ups.

I think I have to dive deeper into this.

I still have Cleanupper v1.x configured, I might just spin that container one back up and see if the behavior is at all different today.

Thanks for your help so far, I think this can be closed for now, as I'm sure I haven't properly pinpointed the right culprit here.

@bentrop commented on GitHub: Somehow, somewhere, my workflow doesn't flow reliably. Bringing everything back online instantly loaded some brand-new malware, Cleanuparr marked it as failed in Sonarr ... but that's it, it just happily kept downloading. At least, nothing triggered any lock-ups. I think I have to dive deeper into this. I still have Cleanupper v1.x configured, I might just spin that container one back up and see if the behavior is at all different today. Thanks for your help so far, I think this can be closed for now, as I'm sure I haven't properly pinpointed the right culprit here.

giteasync commented

@bentrop commented on GitHub:

Alright, I have no choice but to believe you. I have never observed this behavior in v1.x, but the frequency and interval of malware removal has certainly increased since, so it's possible that there are other factors at play.

My hunch is that Deluge trips when the command comes at just the wrong time, possible when a download is moved from the incomplete to the complete folder.

Deluge stumbling sadly has become an almost daily occurrence for me, so I'm looking for a sensible solution. It's admittedly hard to pinpoint the exact cause of the problem.

@bentrop commented on GitHub: Alright, I have no choice but to believe you. I have never observed this behavior in v1.x, but the frequency and interval of malware removal has certainly increased since, so it's possible that there are other factors at play. My hunch is that Deluge trips when the command comes at just the wrong time, possible when a download is moved from the incomplete to the complete folder. Deluge stumbling sadly has become an almost daily occurrence for me, so I'm looking for a sensible solution. It's admittedly hard to pinpoint the exact cause of the problem.

giteasync commented

@Flaminel commented on GitHub:

Maybe lowering the interval might help? Even so, the possibility of removing an item at the wrong time will still be there, but maybe not as often. Is there a way to not use an incomplete directory?

@Flaminel commented on GitHub: Maybe lowering the interval might help? Even so, the possibility of removing an item at the wrong time will still be there, but maybe not as often. Is there a way to not use an incomplete directory?

giteasync commented

@bentrop commented on GitHub:

I still have Cleanupper v1.x configured, I might just spin that container one back up and see if the behavior is at all different today.

This is exactly what I did. I shut down Cleanuppar v2.x and spun up my old Cleanupper v1.x container. As far as I can tell, both have very similar, relatively minimal, configurations. Radarr and Sonarr malware blocking.

This solved all my issues, and Deluge has been running both entirely malware free and rock-solid for roughly a week. The only evidence of malware if the respective apps' histories.

So either there is a regression in Cleanuppar v2.x that's somehow causing blocked files to be removed improperly from Deluge and subsequent crashes, or I'm simply too stupid to configure v2 correctly.

I'm not in a position to judge what is more likely, but I'm reaching out for more help here anyway.
Not sure if this observation warrants reopening this issue yet, maybe you can be the judge on both of those things.

QUEUECLEANER__ENABLED and QUEUECLEANER__RUNSEQUENTIALLY (I found no such option in v2) are enabled, but everything that would trigger it is off. I'm still not certain if this is necessary for CONTENTBLOCKER to work, but that's how it's set up, and it has been working great - but only in v1. v2 constantly crashes Deluge.

@bentrop commented on GitHub: > I still have Cleanupper v1.x configured, I might just spin that container one back up and see if the behavior is at all different today. This is exactly what I did. I shut down Cleanuppar v2.x and spun up my old Cleanupper v1.x container. As far as I can tell, both have very similar, relatively minimal, configurations. Radarr and Sonarr malware blocking. This solved all my issues, and Deluge has been running both entirely malware free and rock-solid for roughly a week. The only evidence of malware if the respective apps' histories. So either there _is_ a regression in Cleanuppar v2.x that's somehow causing blocked files to be removed improperly from Deluge and subsequent crashes, or I'm simply too stupid to configure v2 correctly. I'm not in a position to judge what is more likely, but I'm reaching out for more help here anyway. Not sure if this observation warrants reopening this issue yet, maybe you can be the judge on both of those things. QUEUECLEANER__ENABLED and QUEUECLEANER__RUNSEQUENTIALLY (I found no such option in v2) are enabled, but everything that would trigger it is off. I'm still not certain if this is necessary for CONTENTBLOCKER to work, but that's how it's set up, and it has been working great - but only in v1. v2 constantly crashes Deluge.

giteasync commented

@bentrop commented on GitHub:

Great idea. I just set QUEUECLEANER__RUNSEQUENTIALLY=false in v1 and will see if that causes any issue.
If it does, I'll let you know, and we might be a step closer to the solution.
If it doesn't, I'll once again try to go through it line by line and make sure I recreated my v1 settings in v2 as carefully and closely as possible.

Either way, it will be a while until I have reliable data. I'll let you know once I do.

@bentrop commented on GitHub: Great idea. I just set `QUEUECLEANER__RUNSEQUENTIALLY=false` in v1 and will see if that causes any issue. If it does, I'll let you know, and we might be a step closer to the solution. If it doesn't, I'll once again try to go through it line by line and make sure I recreated my v1 settings in v2 as carefully and closely as possible. Either way, it will be a while until I have reliable data. I'll let you know once I do.

giteasync commented

@Flaminel commented on GitHub:

I'm happy to help and hopefully we can get to the bottom of it. What I need first is to see your v2 and v1 configurations to check for differences and I'd be very curious if setting QUEUECLEANER__RUNSEQUENTIALLY=false would render the same problem as v2.

@Flaminel commented on GitHub: I'm happy to help and hopefully we can get to the bottom of it. What I need first is to see your v2 and v1 configurations to check for differences and I'd be very curious if setting `QUEUECLEANER__RUNSEQUENTIALLY=false` would render the same problem as v2.

giteasync commented

@bentrop commented on GitHub:

Alright, the first test is complete:
QUEUECLEANER__RUNSEQUENTIALLY=false in v1 made zero difference, it's still all completely stable and fully functional. So that's not it.

I once again diligently compared settings between v1 and v2 and recreated everything to the best of my ability. If things start crashing again, there has to be some kind of regression in v2.

If not, you'll hear from me in a week or two, and it was likely just a bug in one of the other apps with some unlucky timing.

@bentrop commented on GitHub: Alright, the first test is complete: `QUEUECLEANER__RUNSEQUENTIALLY=false` in v1 made zero difference, it's still all completely stable and fully functional. So that's not it. I once again diligently compared settings between v1 and v2 and recreated everything to the best of my ability. If things start crashing again, there has to be some kind of regression in v2. If not, you'll hear from me in a week or two, and it was likely just a bug in one of the other apps with some unlucky timing.

giteasync commented

@Flaminel commented on GitHub:

No problem! Feel free to open this back or just update with a comment if you find more context for the problem.

@Flaminel commented on GitHub: No problem! Feel free to open this back or just update with a comment if you find more context for the problem.

giteasync commented

@Flaminel commented on GitHub:

Settings have been added, removed and moved around since v1, but I would not worry about the settings anyway. Is there a particular set of events that happens before Deluge is crashing? Let's say, for example, that both Queue Cleaner and Malware Blocker trigger a download removal.

@Flaminel commented on GitHub: Settings have been added, removed and moved around since v1, but I would not worry about the settings anyway. Is there a particular set of events that happens before Deluge is crashing? Let's say, for example, that both `Queue Cleaner` and `Malware Blocker` trigger a download removal.

giteasync commented

@bentrop commented on GitHub:

Alright, the closer I look, the harder this gets. For many options in v1 there is no v2 equivalent and vice versa - or the description is different.

What is "Delete Known Malware" equivalent to? From the documentation it appears to be just an additional, currently rather brief, name-pattern-blocklist?
Is the deletion process here handled differently from the rest? Could this be a culprit?

Is "Enable *arr Blocklist" the equalivalent to the "*ARR__ENABLED:" flags in v1?

The "Blacklist Sync" description "blacklist patterns will be synchronized to download clients" is rather misleading, given that Deluge supports an (IP/client) blocklist, but no pattern blocklist afaik, so it is almost certainly not supported by this. I assume this simply does nothing if no qBittorrent client is configured?

@bentrop commented on GitHub: Alright, the closer I look, the harder this gets. For many options in v1 there is no v2 equivalent and vice versa - or the description is different. What is "Delete Known Malware" equivalent to? From the documentation it appears to be just an additional, currently rather brief, name-pattern-blocklist? Is the deletion process here handled differently from the rest? Could this be a culprit? Is "Enable *arr Blocklist" the equalivalent to the "*ARR__ENABLED:" flags in v1? The "Blacklist Sync" description "blacklist patterns will be synchronized to download clients" is rather misleading, given that Deluge supports an (IP/client) blocklist, but no pattern blocklist afaik, so it is almost certainly not supported by this. I assume this simply does nothing if no qBittorrent client is configured?

giteasync commented

@bentrop commented on GitHub:

This was fast. After running 100% stable for almost two weeks on v1, the first and/or second malware file removed by v2 broke Deluge. This is the relevant (and slightly cleaned up) Cleanuparr log file-excerpt:

[2025-09-16T17:20:00.022Z] [Information] [Radarr] skip | Unrelated.Download.A
Job: QueueCleaner

[2025-09-16T17:15:00.353Z] [Information] [SYSTEM] episodes search triggered | http://sonarr:8989/ | [Title A S05E05]

[2025-09-16T17:15:00.229Z] [Information] [SYSTEM] queue item deleted with reason AllFilesBlocked | http://sonarr:8989/ | Title A S05E05 Malware-STUFF

[2025-09-16T17:15:00.211Z] [Error] [SYSTEM] failed to remove queue item | Title B S03E05 Malware-STUFF | http://sonarr:8989/
System.Net.Http.HttpRequestException: Response status code does not indicate success: 500 (Internal Server Error).
   at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
   at Cleanuparr.Infrastructure.Features.Arr.ArrClient.SendRequestAsync(HttpRequestMessage request)
   at Cleanuparr.Infrastructure.Interceptors.DryRunInterceptor.InterceptAsync[T](Delegate action, Object[] parameters)
   at Cleanuparr.Infrastructure.Features.Arr.ArrClient.DeleteQueueItemAsync(ArrInstance arrInstance, QueueRecord record, Boolean removeFromClient, DeleteReason deleteReason)
   at Cleanuparr.Infrastructure.Features.DownloadRemover.QueueItemRemover.RemoveQueueItemAsync[T](QueueItemRemoveRequest`1 request)
   at Cleanuparr.Infrastructure.Features.DownloadRemover.Consumers.DownloadRemoverConsumer`1.Consume(ConsumeContext`1 context)

[2025-09-16T17:15:00.209Z] [Error] [SYSTEM] queue delete failed | http://sonarr:8989/api/v3/queue/6xxx7xxx0?blocklist=true&skipRedownload=true&changeCategory=false&removeFromClient=true | Title B S03E05 Malware-Stuff

[2025-09-16T17:15:00.171Z] [Information] [Sonarr] item marked for removal | Title A S05E05 Malware-STUFF | http://sonarr:8989/
Job: MalwareBlocker

[2025-09-16T17:15:00.167Z] [Information] [Sonarr] unwanted file found | Title A  S05E05 Malware-STUFF/Title A  S05E05 Malware-STUFF.iso
Job: MalwareBlocker

[2025-09-16T17:15:00.136Z] [Information] [Sonarr] item marked for removal | Title B S03E05 Malware-STUFF | http://sonarr:8989/
Job: MalwareBlocker

[2025-09-16T17:15:00.077Z] [Information] [Radarr] skip | Unrelated.Download.A
Job: QueueCleaner

I don't know if the successful or the failed deletion caused the crash of Deluge's WebUI, leaving it in a semi-functional state.

Either way, it appears to be still the same problem: going from Deluge’s logs, it looks like the malware file is physically removed before/instead of deleting it from Deluge's queue.

And this exclusively happens with v2, but not v1.

Is there any difference in the request made to Sonarr between v2 and v1?

@bentrop commented on GitHub: This was fast. After running 100% stable for almost two weeks on v1, the first and/or second malware file removed by v2 broke Deluge. This is the relevant (and slightly cleaned up) Cleanuparr log file-excerpt: ``` [2025-09-16T17:20:00.022Z] [Information] [Radarr] skip | Unrelated.Download.A Job: QueueCleaner [2025-09-16T17:15:00.353Z] [Information] [SYSTEM] episodes search triggered | http://sonarr:8989/ | [Title A S05E05] [2025-09-16T17:15:00.229Z] [Information] [SYSTEM] queue item deleted with reason AllFilesBlocked | http://sonarr:8989/ | Title A S05E05 Malware-STUFF [2025-09-16T17:15:00.211Z] [Error] [SYSTEM] failed to remove queue item | Title B S03E05 Malware-STUFF | http://sonarr:8989/ System.Net.Http.HttpRequestException: Response status code does not indicate success: 500 (Internal Server Error). at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode() at Cleanuparr.Infrastructure.Features.Arr.ArrClient.SendRequestAsync(HttpRequestMessage request) at Cleanuparr.Infrastructure.Interceptors.DryRunInterceptor.InterceptAsync[T](Delegate action, Object[] parameters) at Cleanuparr.Infrastructure.Features.Arr.ArrClient.DeleteQueueItemAsync(ArrInstance arrInstance, QueueRecord record, Boolean removeFromClient, DeleteReason deleteReason) at Cleanuparr.Infrastructure.Features.DownloadRemover.QueueItemRemover.RemoveQueueItemAsync[T](QueueItemRemoveRequest`1 request) at Cleanuparr.Infrastructure.Features.DownloadRemover.Consumers.DownloadRemoverConsumer`1.Consume(ConsumeContext`1 context) [2025-09-16T17:15:00.209Z] [Error] [SYSTEM] queue delete failed | http://sonarr:8989/api/v3/queue/6xxx7xxx0?blocklist=true&skipRedownload=true&changeCategory=false&removeFromClient=true | Title B S03E05 Malware-Stuff [2025-09-16T17:15:00.171Z] [Information] [Sonarr] item marked for removal | Title A S05E05 Malware-STUFF | http://sonarr:8989/ Job: MalwareBlocker [2025-09-16T17:15:00.167Z] [Information] [Sonarr] unwanted file found | Title A S05E05 Malware-STUFF/Title A S05E05 Malware-STUFF.iso Job: MalwareBlocker [2025-09-16T17:15:00.136Z] [Information] [Sonarr] item marked for removal | Title B S03E05 Malware-STUFF | http://sonarr:8989/ Job: MalwareBlocker [2025-09-16T17:15:00.077Z] [Information] [Radarr] skip | Unrelated.Download.A Job: QueueCleaner ``` I don't know if the successful or the failed deletion caused the crash of Deluge's WebUI, leaving it in a semi-functional state. Either way, it appears to be still the same problem: going from Deluge’s logs, it looks like the malware file is _physically_ removed before/instead of deleting it from Deluge's queue. And this exclusively happens with v2, but not v1. Is there any difference in the request made to Sonarr between v2 and v1?

giteasync commented

@bentrop commented on GitHub:

Alright, I switched back to v1 for now just to have a running system.

After restarting the Deluge Docker, both "Title A S05E05 Malware-STUFF.iso" and "Title B S03E05 Malware-Stuff.iso" instantly started downloading again ... so neither was successfully removed from Deluge's download queue, regardless of what v2 claimed.

They are, however, no longer in Sonarr's queue.

@bentrop commented on GitHub: Alright, I switched back to v1 for now just to have a running system. After restarting the Deluge Docker, both "Title A S05E05 Malware-STUFF.iso" and "Title B S03E05 Malware-Stuff.iso" instantly started downloading again ... so _neither_ was successfully removed from Deluge's download queue, regardless of what v2 claimed. They are, however, no longer in Sonarr's queue.

giteasync commented

@Flaminel commented on GitHub:

What is "Delete Known Malware" equivalent to? From the documentation it appears to be just an additional, currently rather brief, name-pattern-blocklist?
Is the deletion process here handled differently from the rest? Could this be a culprit?

Just an extra step in the Malware Blocker flow, nothing major there.

Is "Enable *arr Blocklist" the equalivalent to the "*ARR__ENABLED:" flags in v1?

This setting did not exist before. In v1 you only had to set the blocklist type and path and now you also have to enable or disable the functionality.

The "Blacklist Sync" description "blacklist patterns will be synchronized to download clients" is rather misleading, given that Deluge supports an (IP/client) blocklist

Seems like I've forgot to mention that it's a qBittorrent-only feature, although it says that in the docs. I'll fix it asap.

@Flaminel commented on GitHub: > What is "Delete Known Malware" equivalent to? From the documentation it appears to be just an additional, currently rather brief, name-pattern-blocklist? > Is the deletion process here handled differently from the rest? Could this be a culprit? Just an extra step in the `Malware Blocker` flow, nothing major there. > Is "Enable *arr Blocklist" the equalivalent to the "*ARR__ENABLED:" flags in v1? This setting did not exist before. In v1 you only had to set the blocklist type and path and now you also have to enable or disable the functionality. > The "Blacklist Sync" description "blacklist patterns will be synchronized to download clients" is rather misleading, given that Deluge supports an (IP/client) blocklist Seems like I've forgot to mention that it's a qBittorrent-only feature, although it says that in the docs. I'll fix it asap.

giteasync commented

@Flaminel commented on GitHub:

@benjipickard are you using Docker? If so, switch to the fix_deluge_crashing tag and let me know if it still happens again.

@Flaminel commented on GitHub: @benjipickard are you using Docker? If so, switch to the `fix_deluge_crashing` tag and let me know if it still happens again.

giteasync commented

@benjipickard commented on GitHub:

I am using docker in UNRAID. I'll give fix_deluge_crashing a try

@benjipickard commented on GitHub: I am using docker in UNRAID. I'll give fix_deluge_crashing a try

giteasync commented

https://groups.google.com/g/deluge-dev/c/4HwKLChAe_4?pli=1

@bentrop commented on GitHub:

Alright, digging through the trace logs brings me to:

{"result": null, "error": {"message": "Failure: [Failure instance: Traceback (failure with no frames): <class 'deluge.error.InvalidTorrentError'>: cXXcXXXXXXXXeXXXXXXXXXXXXXX3X is not in queued torrents set.\n]", "code": 4}, "id": "38abbc1c"}

which brings me to this discussion:

and a workaround in this comment:

I’ve had the same experience in the autoremove plugin. When you remove a torrent it tries to remove it twice and then crashes. Workaround is to pause the torrents

Looks like it may be a potential bug in Deluge. However, unlike the OP of that old Google Groups post, I have never been able to trigger it with manual deletion from any of the *arrs nor with Cleanuperr v1.

If pausing the affected torrents before removal is a feasible workaround, could that be implemented?

@bentrop commented on GitHub: Alright, digging through the trace logs brings me to: ` {"result": null, "error": {"message": "Failure: [Failure instance: Traceback (failure with no frames): <class 'deluge.error.InvalidTorrentError'>: cXXcXXXXXXXXeXXXXXXXXXXXXXX3X is not in queued torrents set.\n]", "code": 4}, "id": "38abbc1c"}` which brings me to this discussion: https://groups.google.com/g/deluge-dev/c/4HwKLChAe_4?pli=1 and a workaround in this comment: > I’ve had the same experience in the autoremove plugin. When you remove a torrent it tries to remove it twice and then crashes. Workaround is to pause the torrents Looks like it may be a potential bug in Deluge. However, unlike the OP of that old Google Groups post, I have never been able to trigger it with manual deletion from any of the *arrs nor with Cleanuperr v1. If pausing the affected torrents before removal is a feasible workaround, could that be implemented?

giteasync commented

@Flaminel commented on GitHub:

Is there any difference in the request made to Sonarr between v2 and v1?

There shouldn't be, no. It's the same request as before. Any idea on why that deletion failed? You could check Sonarr's logs for that. If these downloads are from public trackers, would you mind joining the Discord server to send me those files? I'd like to test with them.

so neither was successfully removed from Deluge's download queue, regardless of what v2 claimed

Unfortunately that's only the information that Sonarr provides. First removal failed while the second one says it's successful just because Sonarr responded with OK.

@Flaminel commented on GitHub: > Is there any difference in the request made to Sonarr between v2 and v1? There shouldn't be, no. It's the same request as before. Any idea on why that deletion failed? You could check Sonarr's logs for that. If these downloads are from public trackers, would you mind joining the Discord server to send me those files? I'd like to test with them. > so neither was successfully removed from Deluge's download queue, regardless of what v2 claimed Unfortunately that's only the information that Sonarr provides. First removal failed while the second one says it's successful just because Sonarr responded with `OK`.

giteasync commented

@benjipickard commented on GitHub:

I have been experiencing this same exact issue as well since updating to V.2 Was excited to see someone else with the issue but unfortunately no fix yet?

Let me know how I can help.

@benjipickard commented on GitHub: I have been experiencing this same exact issue as well since updating to V.2 Was excited to see someone else with the issue but unfortunately no fix yet? Let me know how I can help.

giteasync commented

@benjipickard commented on GitHub:

Just a note. I can generate the same issue with fix_deluge_crashing or latest version. Just did it with both

@benjipickard commented on GitHub: Just a note. I can generate the same issue with fix_deluge_crashing or latest version. Just did it with both

giteasync commented

@Flaminel commented on GitHub:

fix_deluge_crashing should currently have the same behavior as Cleanuperr v1:

Only delete 1 queue item at a time.
Wait 30 seconds before removing another item.

So if it's still not properly working, there's not much I can do unless you point me to what the problem is.

@Flaminel commented on GitHub: `fix_deluge_crashing` should currently have the same behavior as Cleanuperr v1: 1. Only delete 1 queue item at a time. 2. Wait 30 seconds before removing another item. So if it's still not properly working, there's not much I can do unless you point me to what the problem is.

giteasync commented

@benjipickard commented on GitHub:

I have malware blocker running on 15 seconds scans, (moved to 30), and I search delay set to 120 seconds.

I added log file text to my last post.

@benjipickard commented on GitHub: I have malware blocker running on 15 seconds scans, (moved to 30), and I search delay set to 120 seconds. I added log file text to my last post.

giteasync commented

@benjipickard commented on GitHub:

fix_deluge_crashing still experiencing the problem. When I load a know Malware filetype (.ios) from Sonarr its detects try's to delete and then hangs he Deluge WebUI. Deluge WebUI is still functional and responding somewhat but just looks like a shell of the application.

When attempting to remove the file i notice that the file type in deluge changes status from "download" to "moving" and then it hangs

Here is the deluge log at that time:

Traceback (most recent call last):
File "/usr/lib/python3.13/site-packages/twisted/internet/base.py", line 705, in mainLoop
self.runUntilCurrent()
File "/usr/lib/python3.13/site-packages/twisted/internet/base.py", line 1090, in runUntilCurrent
call.func(*call.args, **call.kw)
File "/usr/lib/python3.13/site-packages/twisted/internet/defer.py", line 877, in callback
self._startRunCallbacks(result)
File "/usr/lib/python3.13/site-packages/twisted/internet/defer.py", line 984, in _startRunCallbacks
self._runCallbacks()
--- ---
File "/usr/lib/python3.13/site-packages/twisted/internet/defer.py", line 1078, in _runCallbacks
current.result = callback( # type: ignore[misc]
File "/usr/lib/python3.13/site-packages/twisted/internet/task.py", line 872, in cb
return callable(*args, **kw)
File "/usr/lib/python3.13/site-packages/deluge/core/torrentmanager.py", line 1607, in on_alert_state_update
self.handle_torrents_status_callback(self.torrents_status_requests.pop())
File "/usr/lib/python3.13/site-packages/deluge/core/torrentmanager.py", line 1667, in handle_torrents_status_callback
status_dict[torrent_id] = self.torrents[torrent_id].get_status(
File "/usr/lib/python3.13/site-packages/deluge/core/torrent.py", line 1037, in get_status
status_dict[key] = self.status_funcskey
File "/usr/lib/python3.13/site-packages/deluge/core/torrent.py", line 1148, in
'total_done': lambda: self.status.total_done,
File "/usr/lib/python3.13/site-packages/deluge/core/torrent.py", line 1076, in status
self.status = self.handle.status()
builtins.RuntimeError: invalid torrent handle used [libtorrent:20]

Here is the Cleanuparr log at that time:

[2025-10-04T18:20:00.171Z] [Error] [SYSTEM] failed to remove queue item | "insert file name here" | http://10.10.10.100:8989/
System.Net.Http.HttpRequestException: Response status code does not indicate success: 500 (Internal Server Error).
at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
at Cleanuparr.Infrastructure.Features.Arr.ArrClient.SendRequestAsync(HttpRequestMessage request)
at Cleanuparr.Infrastructure.Interceptors.DryRunInterceptor.InterceptAsync[T](Delegate action, Object[] parameters)
at Cleanuparr.Infrastructure.Features.Arr.ArrClient.DeleteQueueItemAsync(ArrInstance arrInstance, QueueRecord record, Boolean removeFromClient, DeleteReason deleteReason)
at Cleanuparr.Infrastructure.Features.DownloadRemover.QueueItemRemover.RemoveQueueItemAsync[T](QueueItemRemoveRequest1 request) at Cleanuparr.Infrastructure.Features.DownloadRemover.Consumers.DownloadRemoverConsumer1.Consume(ConsumeContext`1 context)

@benjipickard commented on GitHub: fix_deluge_crashing still experiencing the problem. When I load a know Malware filetype (.ios) from Sonarr its detects try's to delete and then hangs he Deluge WebUI. Deluge WebUI is still functional and responding somewhat but just looks like a shell of the application. When attempting to remove the file i notice that the file type in deluge changes status from "download" to "moving" and then it hangs Here is the deluge log at that time: Traceback (most recent call last): File "/usr/lib/python3.13/site-packages/twisted/internet/base.py", line 705, in mainLoop self.runUntilCurrent() File "/usr/lib/python3.13/site-packages/twisted/internet/base.py", line 1090, in runUntilCurrent call.func(*call.args, **call.kw) File "/usr/lib/python3.13/site-packages/twisted/internet/defer.py", line 877, in callback self._startRunCallbacks(result) File "/usr/lib/python3.13/site-packages/twisted/internet/defer.py", line 984, in _startRunCallbacks self._runCallbacks() --- <exception caught here> --- File "/usr/lib/python3.13/site-packages/twisted/internet/defer.py", line 1078, in _runCallbacks current.result = callback( # type: ignore[misc] File "/usr/lib/python3.13/site-packages/twisted/internet/task.py", line 872, in cb return callable(*args, **kw) File "/usr/lib/python3.13/site-packages/deluge/core/torrentmanager.py", line 1607, in on_alert_state_update self.handle_torrents_status_callback(self.torrents_status_requests.pop()) File "/usr/lib/python3.13/site-packages/deluge/core/torrentmanager.py", line 1667, in handle_torrents_status_callback status_dict[torrent_id] = self.torrents[torrent_id].get_status( File "/usr/lib/python3.13/site-packages/deluge/core/torrent.py", line 1037, in get_status status_dict[key] = self.status_funcs[key]() File "/usr/lib/python3.13/site-packages/deluge/core/torrent.py", line 1148, in <lambda> 'total_done': lambda: self.status.total_done, File "/usr/lib/python3.13/site-packages/deluge/core/torrent.py", line 1076, in status self.status = self.handle.status() builtins.RuntimeError: invalid torrent handle used [libtorrent:20] Here is the Cleanuparr log at that time: [2025-10-04T18:20:00.171Z] [Error] [SYSTEM] failed to remove queue item | "insert file name here" | http://10.10.10.100:8989/ System.Net.Http.HttpRequestException: Response status code does not indicate success: 500 (Internal Server Error). at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode() at Cleanuparr.Infrastructure.Features.Arr.ArrClient.SendRequestAsync(HttpRequestMessage request) at Cleanuparr.Infrastructure.Interceptors.DryRunInterceptor.InterceptAsync[T](Delegate action, Object[] parameters) at Cleanuparr.Infrastructure.Features.Arr.ArrClient.DeleteQueueItemAsync(ArrInstance arrInstance, QueueRecord record, Boolean removeFromClient, DeleteReason deleteReason) at Cleanuparr.Infrastructure.Features.DownloadRemover.QueueItemRemover.RemoveQueueItemAsync[T](QueueItemRemoveRequest`1 request) at Cleanuparr.Infrastructure.Features.DownloadRemover.Consumers.DownloadRemoverConsumer`1.Consume(ConsumeContext`1 context)

giteasync commented

@Flaminel commented on GitHub:

latest has no fix for this issue. If fix_deluge_crashing is not working, I am out of ideas and I am willing to receive suggestions. bentrop provided the same kind of logs and unfortunately they don't help with debugging. I can't reproduce the problem on my side and this issue seems to be specific to a very few Deluge instances (so far just the two of you).

@Flaminel commented on GitHub: `latest` has no fix for this issue. If `fix_deluge_crashing` is not working, I am out of ideas and I am willing to receive suggestions. bentrop provided the same kind of logs and unfortunately they don't help with debugging. I can't reproduce the problem on my side and this issue seems to be specific to a very few Deluge instances (so far just the two of you).

giteasync commented

@bentrop commented on GitHub:

@benjipickard describes the bug to the t. I have the exact same experience. First removal works fine, second one crashes it.

I'm pulling the new version and trying again, but my hope is slowly dwindling. At least v1 keeps working just fine for now.

@bentrop commented on GitHub: @benjipickard describes the bug to the t. I have the exact same experience. First removal works fine, second one crashes it. I'm pulling the new version and trying again, but my hope is slowly dwindling. At least v1 keeps working just fine for now.

giteasync commented

@Flaminel commented on GitHub:

Given that you've waited 120s it's quite clear that the time between removals is not relevant here. I've added back the part where the torrents are paused first, if you wanna pull fix_deluge_crashing again and try that, but it's definitely not something that v1 ever did.

@Flaminel commented on GitHub: Given that you've waited 120s it's quite clear that the time between removals is not relevant here. I've added back the part where the torrents are paused first, if you wanna pull `fix_deluge_crashing` again and try that, but it's definitely not something that v1 ever did.

giteasync commented

@benjipickard commented on GitHub:

Hmm, stange, I will continue my troubleshooting. My Observations currently are, I restart deluge and get it up, restart cleanuparr and verify all connections are good than:

load my first malware file using the sonarr interface and it is detected and properly deleted and indicated in cleanuparr logs
waited 120 seconds
load a second malware file using the sonarr interface and it is detected and cleanuparr attempts to delete but fails and hangs the Deluge Client.

This is repeatable no matter the duration and it only seems to happen after loading a second file following the restarts of applications.

Here is the Sonarr log at the moment it happens:

`025-10-04 10:05:00.0|Fatal|SonarrErrorPipeline|Request Failed. DELETE /api/v3/queue/828800425

[v4.0.15.2941] NzbDrone.Core.Download.Clients.Deluge.DelugeException: Failure: [Failure instance: Traceback (failure with no frames): <class 'deluge.error.InvalidTorrentError'>: e0b04b62917a709e8d6e050174314f8184d04ea4 is not in queued torrents set.
] (code 4)
at NzbDrone.Core.Download.Clients.Deluge.DelugeProxy.ProcessRequest[TResult](DelugeSettings settings, String method, Object[] arguments) in ./Sonarr.Core/Download/Clients/Deluge/DelugeProxy.cs:line 254
at NzbDrone.Core.Download.Clients.Deluge.DelugeProxy.RemoveTorrent(String hash, Boolean removeData, DelugeSettings settings) in ./Sonarr.Core/Download/Clients/Deluge/DelugeProxy.cs:line 148
at NzbDrone.Core.Download.Clients.Deluge.Deluge.RemoveItem(DownloadClientItem item, Boolean deleteData) in ./Sonarr.Core/Download/Clients/Deluge/Deluge.cs:line 219
at Sonarr.Api.V3.Queue.QueueController.Remove(TrackedDownload trackedDownload, Boolean removeFromClient, Boolean blocklist, Boolean skipRedownload, Boolean changeCategory) in ./Sonarr.Api.V3/Queue/QueueController.cs:line 342
at Sonarr.Api.V3.Queue.QueueController.RemoveAction(Int32 id, Boolean removeFromClient, Boolean blocklist, Boolean skipRedownload, Boolean changeCategory) in ./Sonarr.Api.V3/Queue/QueueController.cs:line 92
at Microsoft.Extensions.Internal.ObjectMethodExecutor.<>c__DisplayClass33_0.b__0(Object target, Object[] parameters)
at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.VoidResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeActionMethodAsync()
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeNextActionFilterAsync()
--- End of stack trace from previous location ---
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location ---
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Awaited|20_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
at Microsoft.AspNetCore.Routing.EndpointMiddleware.g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
at Sonarr.Http.Middleware.BufferingMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/BufferingMiddleware.cs:line 28
at Sonarr.Http.Middleware.IfModifiedMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/IfModifiedMiddleware.cs:line 41
at Sonarr.Http.Middleware.CacheHeaderMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/CacheHeaderMiddleware.cs:line 33
at Sonarr.Http.Middleware.StartingUpMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/StartingUpMiddleware.cs:line 38
at Sonarr.Http.Middleware.UrlBaseMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/UrlBaseMiddleware.cs:line 29
at Sonarr.Http.Middleware.VersionMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/VersionMiddleware.cs:line 29
at Microsoft.AspNetCore.Authorization.Policy.AuthorizationMiddlewareResultHandler.HandleAsync(RequestDelegate next, HttpContext context, AuthorizationPolicy policy, PolicyAuthorizationResult authorizeResult)
at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)
`

@benjipickard commented on GitHub: Hmm, stange, I will continue my troubleshooting. My Observations currently are, I restart deluge and get it up, restart cleanuparr and verify all connections are good than: 1. load my first malware file using the sonarr interface and it is detected and properly deleted and indicated in cleanuparr logs 2. waited 120 seconds 7. load a second malware file using the sonarr interface and it is detected and cleanuparr attempts to delete but fails and hangs the Deluge Client. This is repeatable no matter the duration and it only seems to happen after loading a second file following the restarts of applications. Here is the Sonarr log at the moment it happens: `025-10-04 10:05:00.0|Fatal|SonarrErrorPipeline|Request Failed. DELETE /api/v3/queue/828800425 [v4.0.15.2941] NzbDrone.Core.Download.Clients.Deluge.DelugeException: Failure: [Failure instance: Traceback (failure with no frames): <class 'deluge.error.InvalidTorrentError'>: e0b04b62917a709e8d6e050174314f8184d04ea4 is not in queued torrents set. ] (code 4) at NzbDrone.Core.Download.Clients.Deluge.DelugeProxy.ProcessRequest[TResult](DelugeSettings settings, String method, Object[] arguments) in ./Sonarr.Core/Download/Clients/Deluge/DelugeProxy.cs:line 254 at NzbDrone.Core.Download.Clients.Deluge.DelugeProxy.RemoveTorrent(String hash, Boolean removeData, DelugeSettings settings) in ./Sonarr.Core/Download/Clients/Deluge/DelugeProxy.cs:line 148 at NzbDrone.Core.Download.Clients.Deluge.Deluge.RemoveItem(DownloadClientItem item, Boolean deleteData) in ./Sonarr.Core/Download/Clients/Deluge/Deluge.cs:line 219 at Sonarr.Api.V3.Queue.QueueController.Remove(TrackedDownload trackedDownload, Boolean removeFromClient, Boolean blocklist, Boolean skipRedownload, Boolean changeCategory) in ./Sonarr.Api.V3/Queue/QueueController.cs:line 342 at Sonarr.Api.V3.Queue.QueueController.RemoveAction(Int32 id, Boolean removeFromClient, Boolean blocklist, Boolean skipRedownload, Boolean changeCategory) in ./Sonarr.Api.V3/Queue/QueueController.cs:line 92 at Microsoft.Extensions.Internal.ObjectMethodExecutor.<>c__DisplayClass33_0.<WrapVoidMethod>b__0(Object target, Object[] parameters) at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.VoidResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeActionMethodAsync() at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeNextActionFilterAsync() --- End of stack trace from previous location --- at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync() --- End of stack trace from previous location --- at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|20_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope) at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger) at Sonarr.Http.Middleware.BufferingMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/BufferingMiddleware.cs:line 28 at Sonarr.Http.Middleware.IfModifiedMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/IfModifiedMiddleware.cs:line 41 at Sonarr.Http.Middleware.CacheHeaderMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/CacheHeaderMiddleware.cs:line 33 at Sonarr.Http.Middleware.StartingUpMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/StartingUpMiddleware.cs:line 38 at Sonarr.Http.Middleware.UrlBaseMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/UrlBaseMiddleware.cs:line 29 at Sonarr.Http.Middleware.VersionMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/VersionMiddleware.cs:line 29 at Microsoft.AspNetCore.Authorization.Policy.AuthorizationMiddlewareResultHandler.HandleAsync(RequestDelegate next, HttpContext context, AuthorizationPolicy policy, PolicyAuthorizationResult authorizeResult) at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context) at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context) at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task) `

giteasync commented

@bentrop commented on GitHub:

Sadly, I can confirm: not fixed.

It did, however, successfully remove two malware files in a row without crashing or any kind of obvious anomalies first ... it stumbled and fell, as usual, once I ran two of them in parallel.

@bentrop commented on GitHub: Sadly, I can confirm: not fixed. It did, however, successfully remove two malware files in a row without crashing or any kind of obvious anomalies first ... it stumbled and fell, as usual, once I ran two of them in parallel.

giteasync commented

@benjipickard commented on GitHub:

Tried the same sequence again with the new fix_deluge_crashing and it fails on the second file.

Here is the 4 log that generate in cleanuparr when it fails

[2025-10-04T20:32:55.079Z] [Error] [SYSTEM] queue delete failed | http://10.10.10.100:8989/api/v3/queue/828800425?blocklist=true&skipRedownload=true&changeCategory=false&removeFromClient=true | "Insert File Name Here"

[2025-10-04T20:32:55.080Z] [Error] [SYSTEM] failed to remove queue item | "Insert File Name Here" | http://10.10.10.100:8989/
System.Net.Http.HttpRequestException: Response status code does not indicate success: 500 (Internal Server Error).
at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
at Cleanuparr.Infrastructure.Features.Arr.ArrClient.SendRequestAsync(HttpRequestMessage request)
at Cleanuparr.Infrastructure.Interceptors.DryRunInterceptor.InterceptAsync[T](Delegate action, Object[] parameters)
at Cleanuparr.Infrastructure.Features.Arr.ArrClient.DeleteQueueItemAsync(ArrInstance arrInstance, QueueRecord record, Boolean removeFromClient, DeleteReason deleteReason)
at Cleanuparr.Infrastructure.Features.DownloadRemover.QueueItemRemover.RemoveQueueItemAsync[T](QueueItemRemoveRequest1 request) at Cleanuparr.Infrastructure.Features.DownloadRemover.Consumers.DownloadRemoverConsumer1.Consume(ConsumeContext`1 context)

[2025-10-04T20:33:00.017Z] [Error] [Sonarr] Error checking download "Insert File Name Here" with download client binhex-delugevpn
Cleanuparr.Domain.Exceptions.DelugeClientException: Failure: [Failure instance: Traceback (failure with no frames): <class 'deluge.error.WrappedException'>: invalid torrent handle used [libtorrent:20]
Traceback (most recent call last):
File "/usr/lib/python3.13/site-packages/deluge/core/rpcserver.py", line 342, in dispatch
ret = self.factory.methods[method](*args, **kwargs)
File "/usr/lib/python3.13/site-packages/deluge/core/core.py", line 756, in get_torrent_status
return self.create_torrent_status(
~~~~~~~~~~~~~~~~~~~~~~~~~~^
torrent_id,
^^^^^^^^^^^
...<4 lines>...
all_keys=not keys,
^^^^^^^^^^^^^^^^^^
)
^
File "/usr/lib/python3.13/site-packages/deluge/core/core.py", line 734, in create_torrent_status
status = self.torrentmanager[torrent_id].get_status(
torrent_keys, diff, update=update, all_keys=all_keys
)
File "/usr/lib/python3.13/site-packages/deluge/core/torrent.py", line 1029, in get_status
self.get_lt_status()
~~~~~~~~~~~~~~~~~~^^
File "/usr/lib/python3.13/site-packages/deluge/core/torrent.py", line 1065, in get_lt_status
self.status = self.handle.status()
~~~~~~~~~~~~~~~~~~^^
RuntimeError: invalid torrent handle used [libtorrent:20]

]
at Cleanuparr.Infrastructure.Features.DownloadClient.Deluge.DelugeClient.SendRequest[T](DelugeRequest webRequest)
at Cleanuparr.Infrastructure.Features.DownloadClient.Deluge.DelugeClient.SendRequest[T](String method, Object[] parameters)
at Cleanuparr.Infrastructure.Features.DownloadClient.Deluge.DelugeClient.GetTorrentStatus(String hash)
at Cleanuparr.Infrastructure.Features.DownloadClient.Deluge.DelugeService.BlockUnwantedFilesAsync(String hash, IReadOnlyList`1 ignoredDownloads)
at Cleanuparr.Application.Features.MalwareBlocker.MalwareBlocker.<>c__DisplayClass3_0.<b__0>d.MoveNext()

[2025-10-04T20:33:00.019Z] [Warning] [Sonarr] Download not found in any torrent client | "Insert File Name Here"

@benjipickard commented on GitHub: Tried the same sequence again with the new fix_deluge_crashing and it fails on the second file. Here is the 4 log that generate in cleanuparr when it fails [2025-10-04T20:32:55.079Z] [Error] [SYSTEM] queue delete failed | http://10.10.10.100:8989/api/v3/queue/828800425?blocklist=true&skipRedownload=true&changeCategory=false&removeFromClient=true | "Insert File Name Here" [2025-10-04T20:32:55.080Z] [Error] [SYSTEM] failed to remove queue item | "Insert File Name Here" | http://10.10.10.100:8989/ System.Net.Http.HttpRequestException: Response status code does not indicate success: 500 (Internal Server Error). at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode() at Cleanuparr.Infrastructure.Features.Arr.ArrClient.SendRequestAsync(HttpRequestMessage request) at Cleanuparr.Infrastructure.Interceptors.DryRunInterceptor.InterceptAsync[T](Delegate action, Object[] parameters) at Cleanuparr.Infrastructure.Features.Arr.ArrClient.DeleteQueueItemAsync(ArrInstance arrInstance, QueueRecord record, Boolean removeFromClient, DeleteReason deleteReason) at Cleanuparr.Infrastructure.Features.DownloadRemover.QueueItemRemover.RemoveQueueItemAsync[T](QueueItemRemoveRequest`1 request) at Cleanuparr.Infrastructure.Features.DownloadRemover.Consumers.DownloadRemoverConsumer`1.Consume(ConsumeContext`1 context) [2025-10-04T20:33:00.017Z] [Error] [Sonarr] Error checking download "Insert File Name Here" with download client binhex-delugevpn Cleanuparr.Domain.Exceptions.DelugeClientException: Failure: [Failure instance: Traceback (failure with no frames): <class 'deluge.error.WrappedException'>: invalid torrent handle used [libtorrent:20] Traceback (most recent call last): File "/usr/lib/python3.13/site-packages/deluge/core/rpcserver.py", line 342, in dispatch ret = self.factory.methods[method](*args, **kwargs) File "/usr/lib/python3.13/site-packages/deluge/core/core.py", line 756, in get_torrent_status return self.create_torrent_status( ~~~~~~~~~~~~~~~~~~~~~~~~~~^ torrent_id, ^^^^^^^^^^^ ...<4 lines>... all_keys=not keys, ^^^^^^^^^^^^^^^^^^ ) ^ File "/usr/lib/python3.13/site-packages/deluge/core/core.py", line 734, in create_torrent_status status = self.torrentmanager[torrent_id].get_status( torrent_keys, diff, update=update, all_keys=all_keys ) File "/usr/lib/python3.13/site-packages/deluge/core/torrent.py", line 1029, in get_status self.get_lt_status() ~~~~~~~~~~~~~~~~~~^^ File "/usr/lib/python3.13/site-packages/deluge/core/torrent.py", line 1065, in get_lt_status self.status = self.handle.status() ~~~~~~~~~~~~~~~~~~^^ RuntimeError: invalid torrent handle used [libtorrent:20] ] at Cleanuparr.Infrastructure.Features.DownloadClient.Deluge.DelugeClient.SendRequest[T](DelugeRequest webRequest) at Cleanuparr.Infrastructure.Features.DownloadClient.Deluge.DelugeClient.SendRequest[T](String method, Object[] parameters) at Cleanuparr.Infrastructure.Features.DownloadClient.Deluge.DelugeClient.GetTorrentStatus(String hash) at Cleanuparr.Infrastructure.Features.DownloadClient.Deluge.DelugeService.BlockUnwantedFilesAsync(String hash, IReadOnlyList`1 ignoredDownloads) at Cleanuparr.Application.Features.MalwareBlocker.MalwareBlocker.<>c__DisplayClass3_0.<<ProcessInstanceAsync>b__0>d.MoveNext() [2025-10-04T20:33:00.019Z] [Warning] [Sonarr] Download not found in any torrent client | "Insert File Name Here"

giteasync commented

@jababda commented on GitHub:

I'm getting the same error in a truenas + dockage environment as well

@jababda commented on GitHub: I'm getting the same error in a truenas + dockage environment as well

giteasync commented

@Flaminel commented on GitHub:

So it's not just Unraid related.

If possible, I would need access to a Deluge instance (not your main one) for testing to use in my environment, but also a way to restart the instance when it crashes.

Unless any of you provides access to a faulty instance or find a way to reproduce the problem 100% of the time outside of your environment, I can't really do much.

@Flaminel commented on GitHub: So it's not just Unraid related. > If possible, I would need access to a Deluge instance (not your main one) for testing to use in my environment, but also a way to restart the instance when it crashes. Unless any of you provides access to a faulty instance or find a way to reproduce the problem 100% of the time outside of your environment, I can't really do much.

giteasync commented

@benjipickard commented on GitHub:

Do the log files not tell you anything? Is there a different log file that would help?

@benjipickard commented on GitHub: Do the log files not tell you anything? Is there a different log file that would help?

giteasync commented

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

@Flaminel commented on GitHub:

Do the log files not tell you anything?

Other than Deluge fails for whatever reason, they don't tell anything. Cleanuparr does not even remove anything by itself. It just tells Sonarr which in turns tells Deluge to delete stuff.

@Flaminel commented on GitHub: > Do the log files not tell you anything? Other than Deluge fails for whatever reason, they don't tell anything. Cleanuparr does not even remove anything by itself. It just tells Sonarr which in turns tells Deluge to delete stuff.

giteasync commented

@Flaminel commented on GitHub:

So it seems like both of you are experiencing the same problem using Unraid. Unfortunately I am not an Unraid user and I can't extend my trial for some reason. If possible, I would need access to a Deluge instance (not your main one) for testing to use in my environment, but also a way to restart the instance when it crashes.

@Flaminel commented on GitHub: So it seems like both of you are experiencing the same problem using Unraid. Unfortunately I am not an Unraid user and I can't extend my trial for some reason. If possible, I would need access to a Deluge instance (not your main one) for testing to use in my environment, but also a way to restart the instance when it crashes.

giteasync commented

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

@Flaminel commented on GitHub:

I understand, but there's no way to actually find the problem unless I can test for myself. I'm open to suggestions.

@Flaminel commented on GitHub: I understand, but there's no way to actually find the problem unless I can test for myself. I'm open to suggestions.

giteasync commented

@benjipickard commented on GitHub:

Appreciate your efforts and also your application. I Don’t feel comfortable opening up my system to you though no hard feelings.

@benjipickard commented on GitHub: Appreciate your efforts and also your application. I Don’t feel comfortable opening up my system to you though no hard feelings.

giteasync commented

@benjipickard commented on GitHub:

Do the log files not tell you anything?

Other than Deluge fails for whatever reason, they don't tell anything. Cleanuparr does not even remove anything by itself. It just tells Sonarr which in turns tells Deluge to delete stuff.

I can delete stuff all day in sonarr manually in the queue area and cannot force this problem. Only when cleanuparr is telling sonarr does it happen.

@benjipickard commented on GitHub: > > Do the log files not tell you anything? > > Other than Deluge fails for whatever reason, they don't tell anything. Cleanuparr does not even remove anything by itself. It just tells Sonarr which in turns tells Deluge to delete stuff. I can delete stuff all day in sonarr manually in the queue area and cannot force this problem. Only when cleanuparr is telling sonarr does it happen.

giteasync commented

@Flaminel commented on GitHub:

I don't mind it. Cleanuparr seems to work fine for most users and this is only to get it working for you guys, so I'm not bothered. 🤷

@Flaminel commented on GitHub: I don't mind it. Cleanuparr seems to work fine for most users and this is only to get it working for you guys, so I'm not bothered. 🤷

giteasync commented