Completed Download Handling not deleting torrent folder

Sonarr version (exact version): 2.0.0.4855
OS: Windows 10 Pro
Description of issue:
I’ve recently moved from using Drone Factory to Completed Download Handling which is working well except that the torrent folder isn’t being deleted after the video file has been moved by Sonarr. There is nothing special in the folders, just .nfo and .txt files. There is no errors or warnings in the Sonarr logs.

I noticed this occasionally with Drone Factory and am wondering if Windows is interfering in the process as everything is happening in quick succession, rather than on a schedule with Drone Factory which would explain why it only happened occasionally before (when things happen to coincide).

Any ideas?

You should post a bit more information… like which download client :smiley:

My setup has Sonarr communicating with my seedbox which is running a transmission emulator. It sends it the torrents and I can see in Sonarr the download progress. My computer (which is running Sonarr) is scheduled to run a utility (provided by my seedbox) which downloads the torrent pieces and creates the files / folders locally. Once the local download is complete, the utility runs a script which parses the download directory, torrent hash and label to sonarr via the CDH api call. The utility also tells the seedbox to delete the file.

Here is the relevant section in my logs which with my untrained eye looks OK except there doesn’t seem to be any attempt to delete the folder or remaining files after it successfully imports.

I think I understand the problem now after reading the CDH wiki that my setup won’t work as expected because CDH requires that the remote file system be mounted locally and remapped in Sonarr with Remote Path Mapping. Unfortunately the seedbox I use doesn’t support this and never will (it’s been requested before).

Any chance of bringing in an option in the settings to remove the torrent folder after successful import of the video file into Sonarr? You could put one of the orange triangle warnings next to it to say that it is an option that is not required unless the folders aren’t being removed as expected due to an incompatible client, unusual setup etc.

Lol, wait a sec, I didn’t recognize your name…

With that API call you don’t need a remote mount coz you’re taking care of the transfer yourself. If you had a remote mount you wouldn’t need the API call.

In that log file I think we’re missing a few lines at the end, I suggest you retry it but then with log level Trace. Then copy and pastebin the entire section where it starts and finishes processing DownloadedEpisodesCommand.

It should be deleting the folder, so there could be a bug.

Edit: Yeah, it’s a bug.

I’m quite forgettable :stuck_out_tongue:

Thanks for clarifying the ins and out of API calls vs remote mount.

Should I still post a trace level log or is the bug pretty clear?

It’s very clear, already fixed it. It’s like a 3-line fix… and then a page full for the unit tests.

Awesome work!

This is the first bug (albeit small one) I’ve experienced with Sonarr. What is the usual turnaround before your fix makes it into the master branch? I’m not brave enough to try the nightly and risk the wrath of SWMBO :sweat_smile:

master gets released whenever we feel like it’s stable enough. Originally I planned it for last weekend, but delayed it due to some risky changes on friday (which turned out to be a good call coz of a nasty bug affecting only a few platforms)
Atm i’m aiming for later today, but that’s no way guaranteed.

The average between master releases is about a month lately. Years ago it was like once or twice a week, except with risky changes. Most development right now is behind the scenes: Sonarr v3, skyhook (our tvdb proxy).

Thanks man.

No rush on my end, it’s a minor issue after all.

Thanks again :slight_smile:

All working as expected since the new updates. Found this in my log file:

17-8-3 22:10:07.3|Debug|DownloadedEpisodesImportService|Deleting folder after importing valid files

Awesome work, thanks again @Taloth

1 Like

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