Excuse me if I’ve misunderstood the API: I’ve only been using Sonarr for a couple of days.
I’m using the latest version of Sonarr available via Homebrew on El Capitan.
I’ve tried a couple of ways of calling the API method DownloadedEpisodesScan. It works perfectly when a Drone Factory path is set and no path parameter is specified in the API call.
It also logs an error if an invalid path is sent to the API.
However, if a valid path is specified, Sonarr apparently accepts the path and—at some point—appears to strip it to its basename and then chokes on that (invalid) path. What I really don’t understand is why this path works perfectly if it’s the Drone Factory path (and no path is given in the API call), but not when passed to the API as the path parameter.
(The directory exists and contains media files Sonarr understands.)
And the trace log is:
15-10-6 20:49:59.6|Trace|CommandQueueManager|Publishing DownloadedEpisodesScan
15-10-6 20:49:59.6|Trace|CommandQueueManager|Checking if command is queued or started: DownloadedEpisodesScan
15-10-6 20:49:59.6|Trace|CommandQueueManager|Inserting new command: DownloadedEpisodesScan
15-10-6 20:49:59.6|Trace|CommandExecutor|DownloadedEpisodesScanCommand -> DownloadedEpisodesCommandService
15-10-6 20:49:59.6|Trace|CommandQueueManager|Marking command as started: DownloadedEpisodesScan
15-10-6 20:49:59.6|Debug|Parser|Parsing string 'TV'
15-10-6 20:49:59.6|Debug|Parser|Unable to parse TV
15-10-6 20:49:59.7|Debug|DownloadedEpisodesImportService|Unknown Series TV
15-10-6 20:49:59.7|Trace|CommandQueueManager|Updating command status
15-10-6 20:49:59.7|Trace|EventAggregator|Publishing CommandExecutedEvent
15-10-6 20:49:59.7|Trace|EventAggregator|CommandExecutedEvent -> TaskManager
15-10-6 20:49:59.7|Trace|TaskManager|Updating last run time for: NzbDrone.Core.MediaFiles.Commands.DownloadedEpisodesScanCommand
I’m afraid I don’t have the C# chops, or knowledge of the codebase, to trace the call further than DownloadedEpisodesCommandService.cs (which appears to be perfectly correct to me).
I’ve also tried specifying the full path to the video file in question, but Sonarr complains that it isn’t a folder.
Drone Factory is a collection of multiple downloads, so Sonarr will interpret each file and directory in that folder as separate download.
DownloadedEpisodeScan with Path is assumed to be the last stage in a pp-script of a specific download, and thus pointing to the file or folder of that specific download, instead of the parent.
As noted, when I pass the path of the actual video file, Sonarr complains that it isn’t a folder.
It works okay if I pass the path to a folder whose basename corresponds to a show Sonarr knows about—it then processes any files within that folder—but that isn’t much help in post-processing single episodes (which are rarely wrapped in a folder).
In my case it is “the last stage in a pp-script of a specific download”. I download a lot of TV shows from the homeland that aren’t of interest to the Interwebs at large and can only be had from private trackers. As a result, they can’t be downloaded via Sonarr’s built-in mechanisms.
As a “workaround”, I can activate the Drone Factory and dump the files in there manually. I’d just rather they could be handled automatically via my post-processing script.
My confusion stems from the fact that the API falls back to the Drone Factory path, but treats that path differently to an explicitly-specified path. This strikes me as a weird way to behave.
Also, while I’m here: why don’t the API docs explain this?
I’m sure I’m not the first person to ask. And while a lot of people sadly prefer to post a question first rather than try to search for the answer themselves, wouldn’t it be easier to explain this in the API documentation and reply with a RTFM link than to explain the API’s behaviour over and over again?
I’m experiencing the same problem. No matter what the folder is named, unless its specifically named after a TV series that Sonarr is set to track, it will not process any contents of the folder. Been trying to use this API command for my script. The relevant issue is here:
Mostly because the cmd started as a pure dronefactory scan trigger, later extended with path and downloadClientId. The first thirdparty app fully utilizing it was nzbToMedia.
In your particular usecase, why don’t you simply add the torrent to the download client in the same category as sonarr? Assuming the release is named properly, then Sonarr will actually try to import it. It doesn’t have to grab stuff to be able to track and import it.
@mdhiggins Please note that the cmd is async, it’s processed in the background. The json response contains an id that can be used to query the status of the command. The issue you linked to points this out coz the state reported is ‘queued’.
I’ll edit the wiki. There’s an GH issue to improve api docs in general, but well… time.
But in short, the ‘path’ parameter expects to be pointed at a ‘job’ folder, not the root folder. The job folder ideally should be the release name, with the downloaded file(s) inside.
Firstly, because it doesn’t appear to be explained anywhere that adding the Sonarr category will do this. Secondly, because I already assign the torrents to other categories (with private trackers, I need to seed, and I need to know what I need to seed).
This doesn’t make a whole lot of sense when a lot of downloaded files don’t have a containing folder. In such cases, the “job” folder is the root download folder.
As far as I can tell (I haven’t been using Sonarr for very long), it handles files and folders in the Drone Factory folder just dandy. Why can’t it treat the path parameter to DownloadedEpisodesScan the same way (as is implied by the API docs)?
That is to say, the distinction between Drone Factory folder and DownloadedEpisodesScan path seems almost entirely arbitrary.
While it would certainly clear up the confusion by editing the documentation to point out the different treatment of explicitly-specified paths and the default Drone Factory path, I’m certain that this particular behaviour would still remain an issue.
I think it’d be a much better idea if the API actually treated the specified path in the same way as the Drone Factory path.
That would eliminate both the confusion and the problem.
Was this behavior changed recently? I haven’t had any issues pop up with any of the users of my script until now with this. And I’d agree with deanishe that this is a desired behavior is there any way to treat the ‘path’ more like an override of the default Drone Factory Path rather than a special use case with different rules?
Usenet download clients (sabnzbd/nzbget) do create job folders even for single files. That way the release name (nzb name) can be used, and obfuscated files handled properly.
The api call with path is quite different from a drone factory scan. The api with path is always intended for single downloads. It isn’t intended as a catch all, because the temp dir may contain stuff still being downloaded (maybe not in you case, but it does in other). The goal is that it allows the caller to guarantee that the folder only contains stuff that has finished downloading completely and is ready to be moved, avoiding partial transfer issues and such.
Sonarr also expects the folder name to have meaning in that case, and it’s not possible to change that behavior.
So, Api call with path = “hand-delivered envelope”. Api call without path = “check mailbox”.
@mdhiggins, No this behavior hasn’t changed for a long time. But it’s a matter of timing, if the command finishes quickly enough you won’t notice that it’s executed async, that may be the reason why you haven’t noticed it before.
