So, I have found a number of threads about multichannel preference and the difficulties in finding such episodes.
But, would it be possible to provide a feature that post-download blacklists a release, and deletes it from disk is two channel audio is found?
I, personally, have no issue with the multiple downloads that this would mean.
You could do that with a custom script, but it’s not something we’re going to directly support.
@markus101, Thanks. Hm, I could not find a API call for blacklisting a release?
And It doesn’t seem like the EpisodeFile endpoint provides MediaInfo either. So, is there an endpoint that will actually present detected mediainfo? (If not, could THAT be added? 
)
It’s done via /api/history/failed.
It’s part of the episode file response in v3.
@markus101 Ah, Gotcha! I have as of yet not paid v3 much attention. But, okay, then it would be a possibility with the expanded response.
Thank you.
/api/v3/episodefile has it (the same endpoint the UI uses).
@markus101, I just wanted to give a quick pingback and say thank you again. v3 + API will let me do what i want with a moderate bit of effort. Thank you kindly!
@markus101, but wait…
You said
Hm, I could not find a API call for blacklisting a release?
It’s done via
/api/history/failed.
But according to the API guide, the history only supports listing.
So, how do I use the API to actually blacklist a (completed) download?
Looking here https://github.com/Sonarr/Sonarr/wiki/Queue I see that I can blacklist in the Queue endpoint, but only for items that are downloading. In my case the items would already be downloaded.
Not a direct answer, but if I need to cobble something together with the api, I use developer tools in Chrome and click the corresponding button in Sonarr, to see what kind of request is made.
In this case I guess Activity > History > open episode details > History tab > click the x to mark as failed.
If I do that, it ends up in the blacklist.
Right, but you remove and blacklist the grab event, not the import event, which there definitely wouldn’t be an episode file ID for.
I think the current flow would be:
History.Data.ImportedPath with episode files full path (with would be Series.Path + EpisodeFile.RelativePath (Note: will fail if episode file was renamed)downloadId
2 at first glance is a problem, but a lookup by episode ID or download ID would be required.
3 is the awkward part for sure and would be improved with an episode file ID on the history event.
Finding a history event by the episode file ID could fail in several cases (episode file renamed after sorting, was previously deleted), but would result in 0 results. On the other side if an episode file ID is provided with the history event I’d expect to be able to lookup the episode file with that ID, but it may not exist for the same reasons as above, so if we include it we’ll want to consider how to name it to indicate it was the ID at the time of import.
I’ll mention it to Taloth, but I think we could include EpisodeFileId inside of History.Data (it’s a bucket of relevant data for grabs/imports), which would improve step 3, but wouldn’t allow for a lookup directly via the API. Mostly thinking of going with that approach due to the episode files being tossed during upgrades as well as in cases where Sonarr loses the file.
@markus101: Thanks for your in depth explanation.
However I personally think i will use a “on download/upgrade script” to just check new episodes and not really care about the old ones. That should simplify things abit, no? Since i will get the media info and ID quite easily… right?
Yes, you get the ID directly in the script.
So, looking with dev tools i see that a “blacklist release” is actually a post to http://host:8989/api/v3/history/failed
I see the X-Api-Key in the headers, but the form data contains
id=7259
But this ID does not seem to be the epidodeId.
So I am still not seeing the logic here; My external script gets all kinds of good env such as
sonarr_episodefile_id 8732
But, in which order shoukdl i tickle the API endpoints to get back to the ID that “history” wants to perform the blacklist?
I feel like https://github.com/Sonarr/Sonarr/wiki/History is actually missing some information here?
@Thirrian; You made the excellent suggestion to use dev tools to see what was happening… can you shed some light here?
Correct, it’s the history ID. You need to get use the episode ID to get the history for that episode, then find the (presumably latest) grab event (or the grab event related to the latest import event).
soooo, I am missing something. I was home with a man cold this weekend, so I spent some time on this.
sonarr_episodefile_id 8752
Sooo, i go to put that into the history endpoint,
http://thelittlebox:8989/api/v3/history?pageSize=1000&page=1&sortKey=date&sortDirection=descending&episodeId=8752&apikey=…
But then i get:
{
"page": 1,
"pageSize": 1000,
"sortKey": "date",
"sortDirection": "descending",
"totalRecords": 0,
"records": []
}
If i pull up the history in the web ui, I see another episodeID (8577)
{
"page": 1,
"pageSize": 20,
"sortKey": "date",
"sortDirection": "descending",
"totalRecords": 5915,
"records": [
{
"episodeId": 8577,
"seriesId": 13,
"sourceTitle": "Family.Guy.S18E14.1080p.WEB.x264-XLF[rarbg]",
"language": {
"id": 1,
"name": "English"
},
"quality": {
"quality": {
"id": 3,
"name": "WEBDL-1080p",
"source": "web",
"resolution": 1080
},
"revision": {
"version": 1,
"real": 0,
"isRepack": false
}
},
"qualityCutoffNotMet": false,
"languageCutoffNotMet": false,
"date": "2020-03-09T01:45:21.005725Z",
"downloadId": "297CED2656E63FAB993B6B2A545A28E4CA40AA65",
"eventType": "downloadFolderImported",
"data": {
"droppedPath": "/downloads/Family.Guy.S18E14.1080p.WEB.x264-XLF[rarbg]/family.guy.s18e14.1080p.web.x264-xlf.mkv",
"importedPath": "/tv/Family Guy/Family Guy.S18E14 - x264_AAC - Family.Guy.S18E14.1080p.WEB.x264-XLF[rarbg].mkv",
"downloadClient": "Deluge"
},
"id": 7273
},
What conversion am I missing here? How do i get from an “onimport” script run to the history of the file that was actually put on my destination?
You took the episode file ID and used it as the episode ID. Looks like we don’t expose the episode ID(s) in custom scripts, but you can use sonarr_download_id on the history endpoint to filter (assuming it’s available), replace &episodeId=y with &downloadId=x.
@markus101 Aaaaahhh… gotcha!
But, would it not make sense to make the EpisodeID available to custom scripts? Seem to me that it would both simplify things, and be more consistant?
Yeah definitely, I thought it was already, but since it could be multiple episodes (for double episode files), it’ll probably be sonarr_episodefile_episodeids (and be comma separated).
@markus101 Is there any documentation (apart from the source code) for the v3 API?
I’m trying to set the monitored flag for an episode to true. Buuut, the web interface seem to talk to /api/v3/episode/monitor , and (again) i am not sure which ID it expects me to provide in order to toggle the monitored flag? That endpoint does not seem to match the published API-documentation on the web site.
I’m getting close… I can now blacklist the release, and remove the file. All that seem to be left now is to re-enabled the monitored flag (which seem to be set to false when I delete the file, which i suppose makes sense) and there re-triggering a scan for the episode.
anything new in v3 has not been documented, anything in v2 should be the same as v2.
You need the episode ID there, whether you’re updating an episode or a series you need a the the ID of the resource you’re updating.
If you toggle the monitored flag in the UI for the episode it should call that endpoint and you can use dev tools to see it.
It’s unmonitoring on delete because you have Ignore deleted episodes enabled, which is fine, just explaining why. An episode being monitored is not a requirement for the search for an episode to succeed though. It’s assumed that if a user explicitly asks for an episode to be searched they want it regardless of it being monitored.
A season search requires the episodes to be monitored though.