Unable to add torrent file to Deluge

I’m finding the following error pop up in my logs every time the RSS sync is run. I’m not sure how to debug further since this is the only info I have. Interestingly, the deluge web log doesn’t show any access at all at these timestamps. I wonder if the torrent file couldn’t be downloaded, or if there’s a problem with it, but I’m not sure where to look.

NzbDrone.Core.Download.Clients.DownloadClientException: Deluge failed to add torrent [Anime Land] Nanatsu no Taizai - Imashime no Fukkatsu - 02 (WebRip 720p YUV444P10 EAC-3) RAW [98E438F2].mkv.torrent
  at NzbDrone.Core.Download.Clients.Deluge.Deluge.AddFromTorrentFile (NzbDrone.Core.Parser.Model.RemoteEpisode remoteEpisode, System.String hash, System.String filename, System.Byte[] fileContent) [0x000b5] in M:\BuildAgent\work\3a352f0853732683\src\NzbDrone.Core\Download\Clients\Deluge\Deluge.cs:80 
  at NzbDrone.Core.Download.TorrentClientBase`1[TSettings].DownloadFromWebUrl (NzbDrone.Core.Parser.Model.RemoteEpisode remoteEpisode, System.String torrentUrl) [0x00208] in M:\BuildAgent\work\3a352f0853732683\src\NzbDrone.Core\Download\TorrentClientBase.cs:189 
  at NzbDrone.Core.Download.TorrentClientBase`1[TSettings].Download (NzbDrone.Core.Parser.Model.RemoteEpisode remoteEpisode) [0x00148] in M:\BuildAgent\work\3a352f0853732683\src\NzbDrone.Core\Download\TorrentClientBase.cs:117 
  at NzbDrone.Core.Download.DownloadService.DownloadReport (NzbDrone.Core.Parser.Model.RemoteEpisode remoteEpisode) [0x00175] in M:\BuildAgent\work\3a352f0853732683\src\NzbDrone.Core\Download\DownloadService.cs:69 
  at NzbDrone.Core.Download.ProcessDownloadDecisions.ProcessDecisions (System.Collections.Generic.List`1[T] decisions) [0x000dd] in M:\BuildAgent\work\3a352f0853732683\src\NzbDrone.Core\Download\ProcessDownloadDecisions.cs:76 

Full log: https://pastebin.com/mvkzpL2w

Sonarr Version:
2.0.0.5085

Operating System:
Ubuntu 17.10

.net Framework (Windows) or mono (macOS/Linux) Version:
5.4.1.7

We need debug logs to troubleshoot this issue.

Whoops sorry about that. Here’s the trace log: https://pastebin.com/JAuREjTY

It looks like the issue is that the torrent already existed in deluge, and had completed downloading. But sonarr never recognized the completed download. So I removed the torrent, re-ran RSS sync, and the torrent added properly.

However, sonarr doesn’t seem to recognize that it’s finished despite tracking it properly: https://pastebin.com/8jPRkQcy

Marking the download as failed in sonarr fixes the undesired behavior; I haven’t tried downloading that release again.

I’m not sure why the download wasn’t recognized the first time (or second), but I think the deluge response json gives the id of the already-added torrent, so sonarr should be able to recognized that its already been downloaded and check for the file.

Is it in the correct category in Deluge?

Deluge is supposed to return the torrent hash of the download, but it’s not doing that here. It’s returning null, which Sonarr treats as failed to add.

18-2-1 15:20:01.0|Trace|HttpClient|Response content (49 bytes): {"id": "bc6709c3", "result": null, "error": null}

Sonarr is tracking it, but it’s already imported it: SonarrStage=Imported Which indicates in History there is a imported event for that episode linked to that torrent hash.

The category was correct both times it was downloaded.

I double checked the sonarr history - the torrent completed successfully and was successfully imported the first time. Then I deleted the file. Note that my sonarr config does not remove the completed torrent from deluge. Now sonarr attempted to find a replacement release, and settled on the same one it had download before. Sending it to deluge repeatedly failed because the torrent was already there, just paused, so it returns null.

This seems like appropriate behavior for sonarr, and the deluge api could use some more specificity. It might be nice, though, if there was some rough check in sonarr to see if the torrent already exists, like matching the name, so the warning message is a little more direct.

The odd behavior, though, is that it wouldn’t track the download after I removed the torrent and re-added it from sonarr. I’m guessing this is because it sees the import event and ignores the download activity, despite it being a “new” file.

Perhaps deleting the file should also remove the import event so the file can be re-downloaded?

Ideally there would be a unique ID per torrent that is queued, not being restricted by torrent hash, which is how it works for usenet clients, but torrent clients use on the hash.

I don’t think deleting the history event makes sense, that changes too much. The only time we alter history is to remove it when a series is removed.

Perhaps we can improve the logic and ignore the previous event when a grabbed event is added after the import event.

Thanks for the help.

The only reliable way of tracking them is by infohash because torrent clients rarely have persistent unique ids.
This is especially problematic if people switch torrent client and keep seeding.

Either Sonarr should refuse adding the torrent, or indeed ignore the previous import event if it’s grabbed. This won’t cover the scenario where the user manually adds it to the client.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.