Jackett: [req] Bulk import indexers to Sonarr/Radar

[backsofangels]

[QOL improvement]

Possibility to create a txt/JSON file to have a bulk import of indexers to Sonarr/Radarr, to automate the process of adding each indexer manually, with a workflow similar to this one

• Add indexers to Jackett
• Hit the "Export indexers list" in Jackett
• Creation of a JSON file readable by Sonarr/Radarr
• Hit the "Import indexers from file" button in Sonarr/Radarr

Of course, in Sonarr/Radarr this feature doesn't exists yet, will make a similar request to their repos soon.

[hadim]

Can you link to the issue you've made on Radarr and Sonarr?

That feature would be super nice indeed!

[ngosang]

@backsofangels The import functionality is not available in Sonarr. If someone is interested request that feature in Sonarr, Radarr, Lidarr... repositories and we will implement this after.

[hadim]

Here are the issues:

• radarr: https://github.com/Radarr/Radarr/issues/3569
• sonarr: https://github.com/Sonarr/Sonarr/issues/3170

Both are now closed because devs said that Radarr and Sonarr have API to be able to do that.

I think a structured file format (such as JSON/YAML) would be preferable in terms of portability and interoperability. Also, it would prevent Jackett to have any specific software-specific code (related to Sonarr/Radarr API).

[cadatoiva]

I think the API interop already in Sonarr/Radarr would be the better option. The whole point of this project in general is to create a seamless interop layer with these programs so they don't have to do extra work to get trackers running/keep them up to date. An export button in our UI with a dropdown or even checkboxes for multiple program export would be a good feature enhancement for Jackett.

[hadim]

If you guys agree to build an export option for Sonarr/Radarr then it's perfect :-)

[ngosang]

Jackett configuration is in JSON format in the file system and Jackett also has a REST API.
It is really easy to write a third party script that read the Jackett config, transform and send it to Sonarr.

IMHO It's out of the scope of this project to configure external programs.

[cadatoiva]

@ngosang do we have documentation to facilitate a 3rd party accessing the torznab links for configured trackers? At this point, none of the projects are willing to make this an integrated feature, and I know that I for one would love to have this kind of feature officially supported in one way or another.

[ngosang]

@garfield69 Know better the available doc.

I think all you need for this task is:

• Jackett config (all config you can see in Jacket UI: api_key...) => GET http://127.0.0.1:9117/api/v2.0/server/config
• All indexers (the indexers configured have the flag configured=true, you can get supported categories, private/public, language...) => GET http://127.0.0.1:9117/api/v2.0/indexers

Both APIs are in JSON format and don't require additional parameters.

UPDATE: If you don't have experience with REST APIs I recommend you to try Python 3 + Requests module. You should be able to do this task in 20 lines, 12 if you remove validations.

[hadim]

Indeed it would be easy to make a Python script but I would prefer to have a button either in Sonarr/Radarr or Jackett...

[cadatoiva]

Yeah, that looks like it has all that would be needed + knowledge of how the URLs are formed.

IMHO I still think this should ultimately become first class integrated on one side of the pipeline, as it is a highly requested feature out on the wild interwebs. Maybe replace the copy button with an export, and one of the export options be "Copy to Clipboard" in the resulting popup.

[ngosang]

The button should be in Sonarr, but looks like that is not going to happen...

• You are already configuring Sonarr with Jackett config. If you add Sonarr config in Jackett you have a circular dependency...
• If they are not going to do the import, you still need the script to call the REST API. There is no point in doing the Jackett export...
• What should be the export format? Jackett is used by more than 10 apps that I know (I'm sure there are many more). We have to add export button for Radarr too? for Lidarr?
• The most important reason => The goal of Jackett is to make the best torrent aggregator. That means to support a lot of sites and keep all updated. If we start adding integrations with external apps in few months this Github will be full of requests/issues and we won't have time to focus in the main goal.

[hadim]

I understand your point @ngosang. In that case would you consider adding a simple structured file format export function. Exact format would be decided by you guys (happy to help) and then free to upstream apps to use or not.

[hadim]

If no apps want to add this feature then it could still be used by scripts (without having to call the Jackett API).

[cadatoiva]

I mean, my thought on this would be to use existing APIs where available and make it a low priority feature. We could even go so far as to make the entire export system akin to our current YAML system for torrent sites, and leave most of the burden on the other apps to implement a system to integrate into ours. We already don't just aggregate torrents, but proxy the results to 3 different export formats (NZB, RSS, & Potato), with the expectation that our application will be used as an intermediate for other search/grab systems.

I think adding a system to better facilitate those systems integrating with ours further by creating an API/spec that is very simple for them to use/maintain would help bridge that last gap. I don't think it should be high priority at all, and that for all but the most popular apps we tell users to go to the other app to implement what we already support, kinda like we already do with our 3 interfaces for results & searching.

[bakerboy448]

NZBHydra2 has this...it'll use the API to push the config Sonarr/Radarr for the user
https://github.com/theotherp/nzbhydra2/blob/master/core/src/main/java/org/nzbhydra/externaltools/ExternalTools.java

Can't be too hard to port and embed, no? @ngosang

[ngosang]

It's easy to port but, as I said before, it's out the scope of Jackett. Jackett is a proxy/middleware/aggregator and his responsibility is to make requests to different trackers and convert the response into a standard format that can be used by other tools. Jackett has a stable API to get all the indexers and other apps can do the integration with us.
In addition to the architectural decision, we don't have the man-power to integrate with external tools, change the web UI, support different versions of Sonarr (v2 is very different form v3), resolve related issues...
If Sonarr/Radarr developers are not interested, someone can do a simple Python/Bash script to grab indexers from Jackett API and publish them in Sonarr API. Will be a 3rd party tool not maintained by us (in other repository).

[bakerboy448]

if it is in Hydra's scope then it is in Jackett's scope as they serve the save purpose, no?

You're also mistaken, the APIs between Sonarr (and Radarr et. al) v2 and v3 are materially similar, so I'm not sure why you think "v2 is very different from v3) from an indexer and api standpoint that is not the case at all. It's also all API based, so I'm not sure what related issues you're talking about? I don't for see the indexers api changing in any material way that would break an indexer creation.

the consensus is the Sonarr devs refuse to do anything they don't personally want....

It would make much for sense for an indexer aggregator to push it's info to a client than to have the client pull from the indexer aggregator.

if it's easy to port, then why not port it, mark it as beta/unstable and call it a day?

[ngosang]

the consensus is the Sonarr devs refuse to do anything they don't personally want....

And we have to add this, even if it's a bad decision, because they don't want to? You are already configuring Jackett's URL in Sonarr and Sonarr knows how to call Jackett. It's clear to me they should add a button in the indexers tab to import Jackett indexers.

It would make much for sense for an indexer aggregator to push it's info to a client than to have the client pull from the indexer aggregator.

Wrong. The client calls Jackett when required, Jackett don't push anything.

if it's easy to port, then why not port it, mark it as beta/unstable and call it a day?

This is not going to be implemented in Jackett because it's a bad architectural decision and it's going to hurt the project in the long run. Should be implemented in Sonarr, but, if they don't want to, you can write your own script to do the task.

I'm not going to change my mind. This issue is open for other users not to duplicate the request.

[austinwbest]

@ngosang Would you be able to add an endpoint for configured indexers instead of a dump of everything? Save passing in a ton of things that are not needed.

I'm working on implementing it into Radarr so if you could, that would be appreciated.

/api/v2.0/indexers/configured or something similar that returns only configured=true

[ngosang]

@austinwbest that feature is already implemented long time ago.

• /api/v2.0/indexers => all indexers
• /api/v2.0/indexers?configured=true => only configured indexers

[austinwbest]

I didn't look at the api, just went based off an earlier post.

Thanks.

[zero77]

@ngosang
Is this in the documentation.

[ngosang]

Is this in the documentation.

No, sorry. These APIs are consider "internal" right now, but they are very stable. If you need something just quote me and I will take a look at the source code for you.

In the long term I want to implement a stable public API in Jackett with a better design and documentation but it can take years, so, use the internal API by now.

[zero77]

@ngosang
Thanks