So I'm sorry to say things aren't working very well. I'm hoping you or @Taloth may be able to shed some light.
I was seeing success when I was running the TorrentToMedia.py script manually, like this:
TorrentToMedia.py 234004f6071ce63e5e912201d9a999885d59103a My.Show.S01E19.HDTV.x264 D:\queue\processing\tv\torrent
This cause the script to look for the directory
D:\queue\processing\tv\torrent\My.Show.S01E19.HDTV.x264 and copy/extract it to the defined output directory which I have defined as
This worked, and after extraction (or just copy in the case of no rar) it sent the API call to Sonarr. Sonarr then did 3 things:
1) Imported from the
2) Removed the files from
D:\queue\pickup\tv (because #1 was successful)
3) Removed the download from deluge, which also served to delete
So the net effect was file got into my media folder through Sonarr and all other copies were deleted. Perfect!
However, when running an actual download through Sonarr, the problem arises where Sonarr will actually scan the
D:\queue\processing\tv\torrent\My.Show.S01E19.HDTV.x264, seeing how that is the information it has been passed to it by deluge.
In the case of a rar file this shouldn't cause a problem (I don't think) because it won't find anything to import there and so the call from NTM should trigger the import from the pickup directory.
However, for a file that isn't archived what happens is that even thought the file gets copied from
D:\queue\processing\tv\torrent\My.Show.S01E19.HDTV.x264 to the
pickup folder, Sonarr uses the deluge path and grabs the copy from the former. This leaves the latter directory there with an extra copy of the data.
At this point I thought that I probably needed to implement the remote path hack that @taloth mentioned. But, it doesn't appear to work when everything is on the same box. To be clear, I added "10.10.10.102" and "d:\empty" to both path locations. But, the logs show it always still going out to pickup from the processing directory.
I think I can probably fudge this by setting
force_clean = 1 in the NTM script. But this doesn't seem like a graceful solution, and I'm not sure how safe it is either.
Pretty discouraged that there is no standardized way to do this and the only real option is to use the drone folder which we are discouraged from doing.
Ok, so I got this working again though I don't know how ideal it is.
It turns out I have some of the same issues as you do with your data on a separate seed box because my download location and final media location are actually on separate drives on the same box - which means hard-linking won't work.
What this means is that the intended pickup directory (what you called "drone") will still keep a copy of the files in them unless you either edit the NTM code to add the
"importMode": "Move" option or use
force_clean = 1. The "Move" is probably safer, because what is unclear is this:
When NTM sends the process command to sonarr, how long does it wait? Does it actually wait for a successful response that Sonarr has copied/moved/linked/whatever the file? Or does NTM just wait a certain time after the process command is send. If the latter case, and NTM just continues on processing after so many seconds, then
force_clean = 1 could be very dangerous as it might wipe out a file (or at least try and then fail...depending on locks) before Sonarr fully gets it.
So I'm a little suspicious of just using
force_clean = 1 by itself. However I must use it because as I am on a single box, this hack with the remote path mapping doesn't seem to work at all. This means that Sonarr will always scan the final torrent location (after move) and get the copy from there. Since it will have already processed the movie (or at least begun to) by the time NTM sends its notification, Sonarr will not then try to process it from the NTM pickup location. This means that copy of the data will simply remain unless you use force clean.
I'm considering changing my label to move the finished torrent directory to the same drive the final media (seasons) are on. I have a concern though that Sonarr may start scanning that location before the file finishes copying. My guess is that Sonarr doesn't know that a "move completed to" is taking place when it checks to see if the torrent is complete...so it might start processing before a move to another drive has a chance to happen. I hope @taloth or maybe @markus101 can chime in on that front. I'm going to open another thread maybe on this question because I see another weird issue that might relate to a race condition here.
In the end, I think this will work...but it is kludgey and I'm not crazy about it. I'll have to let it run for a few weeks and see how clean it is.