Jackett: Automatically try alternate URL and/or disable failing scrapers?

[dairefagan]

Is it possible to configure it so that when trackers are failing Jackett will automatically try an alternate URL where one is available, otherwise disable the tracker completely?

[ilike2burnthing]

Disabling indexers currently isn't possible, but the request has been made https://github.com/Jackett/Jackett/issues/661, as has one to automatically disable on failure https://github.com/Jackett/Jackett/issues/3292.

I'm not sure if trying alternative sites on failure has been suggested before though. Personally, if implemented, I'd want that to be optional, perhaps even on a per indexer basis.

[dairefagan]

Thank you, I am following both tickets now.

Can you explain why you would not want to try other sites, perhaps a case when the main site is just down temporarily?

Also, is there any way to use profiles with Jackett or a workaround for same? It took time for me to select the ones that work for me, which is now ~20 but sometimes I may want to search all possible trackers for something difficult to find, or for a type of media I usually do not search for.

[ilike2burnthing]

Oh it's just a personal thing, I want to know when sites go down so we can keep track of them.

I suppose it depends on the implementation. Currently, when a site redirects, if followredirect: true is part of the .yml, the user will receive a notification, and on the next attempt the redirected URL will be used instead. So if we had something like allowfallback: true that at least gave a notification, then I'd be fine with that.

Though with Sonarr/Radarr/Lidarr/whatever also triggering this, I'd want some way to identify this having happened when Jackett wasn't open, perhaps a yellow exclamation mark instead of a red one. Apologies to whoever I end up giving extra work to 😋

As for profiles, see the current requests https://github.com/Jackett/Jackett/issues/2185, https://github.com/Jackett/Jackett/issues/8884, and https://github.com/Jackett/Jackett/issues/4787, with the latter detailing a current workaround (also described in #661).