Sonarr + Filebot + Transmission and Completed Download Handling problems (solution)

Help & Support
#1

This is for people who:

  • download torrents using Transmission (though some of this information might apply to other download clients)
  • use Filebot to process episodes fetched by Sonarr
  • also use Filebot to process episodes downloaded without Sonarr and/or to process movies
  • download compressed files

As you are probably aware of, if you have Filebot set to process all downloaded files, it will interfere with Sonarr’s Completed Download Handling, which means episodes are not automatically detected and imported by Sonarr. The files will not be registered until the periodic task Refresh Series is run, which is once every 12 hours. In the meantime, episodes might be downloaded again, because Sonarr doesn’t know it’s there. And even if an episode is not downloaded twice, it’s still annoying to see the episode as missing in Sonarr. I will show you how you can set things up so that Filebot will post process every file you download (both series and movies), while still letting Sonarr import the files that have been fetched by Sonarr (using Drone Factory). With some download clients, this is easily done using labels. For Transmission, it isn’t quite as straight forward…

Solutions to this problem have already been suggested in related topics, e.g. forcing a refresh after every download. This is just a different approach that I personally prefer.

While I really love Sonarr, my automated media center would not be complete without Filebot. I need it for organising my movies, and also to unzip series, since 90% of the content I download is compressed, and Sonarr doesn’t have that feature yet. I have Transmission (though almost any bit torrent client can do this) set up to run the Filebot Automated Media Center script after a download is complete. The workflow is:
Sonarr fetches new episodes or I download a series/movie manually -> Filebot takes care of everything else when the download is complete.

When a download is complete, Filebot will unzip, rename, clean up and move the file to my Media folder (in which I keep all of my sorted and renamed TV shows and movies). This interferes with Sonarr’s own Completed Download Handling, as it wants to do the same job, but by the time it gets going, Filebot has already moved the files.

So what we want is to have Filebot process every download, but let Sonarr move the files that it has fetched itself. So somehow, Transmission needs to know whether the file was fetched by Sonarr or not. Since Transmission does not support labels, we will do it by changing Sonarr’s download directory to one that differs from Transmission’s default settings, and use this directory kind of like a label. Every torrent in Transmission has environmental variables, and one of these is called TR_TORRENT_DIR. Thus we can filter torrents based on the chosen download directory.

Solution:
Take a look at the Transmission settings in Sonarr: filling in the Category field would make a subfolder inside Transmission’s default download directory, but this is not recommended, as that can mess things up when the Filebot script is running in parent folders. Instead, enable advanced settings and choose a directory outside the default one. E.g. this setup would work:

…/Transmission/Incomplete
…/Transmission/Completed
…/Transmission/Sonarr/Completed
…/Transmission/Sonarr/Drone Factory

The first folder contains all incomplete downloads. The second is for completed downloads which were not fetched by Sonarr. The third is for completed downloads which were fetched by Sonarr (the one we specified above), and the last is our Drone Factory folder.

When that is done, turn off Sonarr’s Completed Download Handling (remember, Filebot is doing all the post processing). Now turn on Drone Factory and set a path like the one above with a scan interval > 0.

All that remains now is to modify Transmission’s post process script with an if/else block. Here’s how I have it set up:

if [[ $TR_TORRENT_DIR == *"Sonarr/Completed"* ]]; then
	filebot -script fn:amc --output “$TR_TORRENT_DIR/../Drone Factory” --action move…
else
	filebot -script fn:amc --output “/Users/rosemacmini/Media” --action move…
fi

In other words: if the file was fetched by Sonarr, tell Filebot to output it to the Drone Factory, where it can be picked up by Sonarr. In every other case, move the file directly to the Media folder.

Note: the default naming format of the Filebot AMC script is /TV Shows/ShowTitle/SeasonNumber/ShowTile-EpisodeNumber-EpisodeTitle, which means it will create subfolders inside the Drone Factory, thus preventing files from being detected. To prevent this, simply pass a series format expression to the AMC script (e.g. seriesFormat="{n} - {s00e00} - {t}”)

Say goodbye to episodes being downloaded twice!

#2

Some comments (please don’t take it as negative criticism)

Don’t use Drone Factory. You may say “I need it”, but you don’t. It’s pretty much never the only option, and will get removed in future Sonarr versions.

There are two possibilities, but the best option is to:

  1. Have filebot dump it in a temporary folder.
  2. Then call the Sonarr POST /api/command.

That will tell Sonarr which download the files belong to. And ensure it’s an atomic action. Sonarr won’t try to import intermediate files.
The nice part about it is that Sonarr will be able to associate the import to the original grab event and potentially use identifying information from the grab.

The wiki on the api doesn’t have alot of examples, but there are some on the forum. Basically you just post a json object to the api. { "name": "DownloadedEpisodesScan", "path": tempDir, "downloadClientId": infoHash, "importMode": "Move" }

#3

Thanks for the feedback. After thinking about it, I agree that sending a command to Sonarr is a better option. And knowing that Drone Factory will be obsolete in future versions is enough motivation for me to change my approach. I just have a question about the infohash:

In the API command, I’m passing the path of a subfolder inside the temporary folder. This subfolder has the exact release name, thus Sonarr is able to pick up the video quality. However, the video file inside the subfolder has already been renamed by Filebot, and I noticed that when I pass the infohash and it is used by Sonarr in conjunction with CDH, Sonarr will revert the file back to its original release name before importing it (understandable, because I have turned off renaming in Sonarr).

I know I could have Filebot not rename the file - only unzip it - but I don’t like the idea of having two different programs renaming my series. I.e. if I would manually download a Blu-ray box set later on, the filenames need to be exactly the same to avoid duplicates.

Basically I’m wondering if Sonarr is missing any critical associative information without the hash? As I said, I have already confirmed that the video quality is being picked up without it.

#4

I don’t understand, if renaming is off it shouldn’t rename, unless it thinks it’s an obfuscated filename, it’s a bit complicated coz it pulls info from various sources.
It’s something I’ll have to test out. I’ll need to have the original releasename, the original filename, the filebot directory name, and the filebot renamed filename. That should allow me to replay the scenario.

No it’s not critical, especially if you can guarantee the folder name is correct.

Some torrent clients behave differently for single-file vs multi-file torrents. With multi-file torrents, the output subdirectory is the original .torrent filename… the releasetitle. With single-file torrents, it’s often without a subdirectory.
The torrent title (in the client UI & api) often adopts either that subdirectoryname (which is the original releasetitle) or that filename (which could be anything). In the later case the original (potentially dirfixed) releasetitle would be lost.
In these edge-cases the ‘associative’ capability helps Sonarr to resolve it.
I don’t know if this is applicable to transmission, but I figured I’d explain one of the scenario’s where the association helps.

#5

What I mean is that since the release name is in the hashinfo, it’s understandable that Sonarr uses this name when importing the file, since I haven’t set up Sonarr to rename the file for me. It doesn’t matter if Filebot has already renamed the file, because since the hash contains the original name, that is what Sonarr will use.

I’ve tested this on various files, both by renaming manually and using Filebot, but here’s an example:
Release name: South.Park.S20E10.WEBRip.X264-FUM
Original filename: South.Park.S20E10.WEBRip.x264-FUM.mp4
Filebot renamed filename: South Park - S20E10 - The End of Serialization as We Know It.mp4

The directories are like this:
…/Sonarr/Completed
…/Sonarr/Temp

The first folder is (obviously) where completed Sonarr downloads end up. The Filebot script is called on a subfolder in this directory, i.e. on:
…/Sonarr/Completed/South.Park.S20E10.WEBRip.X264-FUM (containing South.Park.S20E10.WEBRip.X264-FUM.mp4)

Filebot then renames the file inside the folder to:
…/Sonarr/Temp/South.Park.S20E10.WEBRip.X264-FUM/South Park - S20E10 - The End of Serialization as We Know It.mp4

Finally, Sonarr receives the API command with the parameter “path”: “…/Sonarr/Temp/South.Park.S20E10.WEBRip.X264-FUM”, instructing it to import the file inside that folder (South Park - S20E10 - The End of Serialization as We Know It.mp4). But when the hashinfo is passed, Sonarr will ignore the current filename and use the original release name instead when moving/importing the file. If renaming in Sonarr was turned on, it would of course at the same time rename the file properly, but it isn’t. When the hash is not passed, Sonarr will use the current name of the file (the one set by Filebot earlier).

So I guess I have two options:

  1. Set up renaming in Sonarr
  2. Don’t pass the hash. Which is what I will do based on your response about the hashinfo.

I’m not sure how Transmission works with single-file torrents, because all releases on the tracker I use has multiple files (always .nfo). But that’s good to know if I ever come across one. Thanks for the clarification!

#6

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