Indexers: They work fine in Jackett but errors for Sonarr (connection refused)

if limetorrent doesnt miscategorise files very often then you can remove 5070 from the main category list to drop out all the anime file results from a normal search.

radarr is for movies, so you want to set a category of 2000,7010 there for a limetorrent indexer

you could drop the 7010 if movies dont end up under “other” very often. for the moment you may want to leave it in to see how you go

there were no fields for categories in the radarr setup. url, api key were it (and name). toggles for rss and search.

you may have used the wrong indexer type, or you may have an old version of radarr? i have version 0.2.0.1480 (linuxserver docker image)

my torznab (what you use for jackett) based indexer options look like this (currently disabled as i dont use this one at the moment)

Radarr Ver. 02.0.1480

Embarrassing … been here for an hour not able to add a single additional index to even Sonarr.
Same method.

  • Select a source from Jacket. Source test passes. Search test passes.
  • In Sonarr, add the url (change the local host to the 172 jacket ip,) add the key and add a few category numbers listed in the source specs page; anime left blank. Also used same categories as from last night’s success.
  • All results are the same “No results were returned from your indexer, please check your settings.”

NzbDroneErrorPipeline Invalid request Validation failed:
– No results were returned from your indexer, please check your settings.
FetchAndParseRssService No available indexers. check your configuration.


In the mean time, also trying to get transmission (desktop Mac) app connected. Have the web interface activated, think the ports are correct…googling.

delete the sonarr, radarr, and jackett containers (it wont delete the underlying data). then create them again. its seems like something is wrong at a really low level.

k. will kill 'em. containers only (not images.) Hesitant, as it took a while to build. Settings are known and saved so hopefully back up quickly.

UPDATE
cool…had to run the config commands and no data appears lost.

Add - Torznab still not showing option for categories.




Still unable to add additional indexes to Sonarr…man alive…
I would wipe the computer to factory default if I thought it would solve the problem.
If the one index added to sonarr, then its not a permissions issue etc.

(experimented w/various categories, even including all of them offered by the respective index)

for radarr - on the indexers page, tun on advanced settings

image

then add your indexer and you should see the extra options

for sonarr - can you enable trace logging and do a search, then disable it and post the log file somewhere

you may also want to double check the jackett logs as well. should be under the /config/jackett folder

Ah,saw the advanced and didn’t realize that also changed options for the add panels.

Alas, same result. This example uses the exact same settings as the working Sonar index for Lime



SONARR LOG


JACKETT LOG
(non trace, from Docker settings for Jackett) -> https://pastebin.com/6jhuDGzP

JACKETT LOG
(from Jackett directory) -> https://pastebin.com/tTF72hfF

Logs are under the previous response…

Finding something different here and wondering if this might a problem?
Sonarr and Radarr have relatively similar directory structures. From the post stating the log would be with the config file, presuming the same might be true for Jackett.

While Jackett appears to be up and running just fine, the directory structure appears different.
Here is an image of the setup config file and its respective directory structure.
Is Jackett meant to be in it’s own directory like that, or possibly the target Downloads and Video files are meant to be together, and at the higher level?
image

Experimented adjusting the directory to bring DataProtection, Indexers, log.txt and ServerConfig.json up a level to see what might happen. Restarting docker, and having to restart Jackett, Docker created the Jackett directory again. Strangely enough, no impact to the data everything was still there. Anyway, restored the original directory. Experiment failed.

KEY UPDATE

Started a completely fresh Jackett; different directory, key etc. Commands you have shared here have helped, so was able to go into shell of the new Jackett instance, get the ip, ensure the categories match etc.

Successfully added a few indexers (YEA!! Amazing)


Go to add the forth (this one would be TorrentProject2), it tests fine, manual search fine.
Throws an error “No results were returned from your indexer, please check your settings.”

Try another (ExtraTorent) - tests, search all good… same error adding to Sonarr.
Almost as if something changes somewhere along the line and prevents adding more? This was all in one session btw, adding three no problem then hitting the wall on number 4, and 5.


I was able to add those successful indexes to Radarr (yea!), and failed on those same two above. These two test, manual search are working, category codes are accurate…baffled.


Success at adding a few more indexes to both Radarr and Sonarr now, and still failing on the others. These are probably enough to get me going, maybe not worth the time to chase after a few index problems at this stage as the states of getting Transmission (desktop) connected and then VPN (where I can still remote in) lie ahead.


@rhom @markus101

Thank you for taking the time to help on this. You both have taught me a fair amount where I was able to use some of that to get past my own earlier limitations. Hope you both decide to pitch in on the remaining steps ~ which I will post separately so we can close out this thread. Thank you once again. :grin:

jacket having a jackett folder under config is a bit non standard but it seems thats how they set it up.

its also generating this warning, which doesnt appear to be an issue but you may want to check on the jackett forums.

Warn No XML encryptor configured. Key {b1301308-eb7e-4dc0-9dd4-5aff79ac184d} may be persisted to storage in unencrypted form.

but it doesnt appear on more recent startups so the rebuild may have fixed those

youre also getting Resource temporarily unavailable on limetorrents so that indexer may be having its own (temporary) issues. maybe try later.

im presuming the initial connectivity issues may have been due to an ip address change and youve catered for those already? or did jackett end up with 172.17.0.3 again?

the sonarr trace logs dont seem to have captured a full search, there is what looks like the end on one, maybe, but the error points to getting no response from jacket (as if the ip address was wrong?)

do you have any anti-virus / web protection software on your mac that could be interfering? perhaps disable it temporarily to see if they start working ok?

I am using a new version of Jackett w/a different IP. While I do not know enough to know how well it all working, this is all much better than past setups and attempts.

Testing, I did a Plex search, selected a few random episodes which is now with Transmission.
Transmission is working as expected, and I think the red bars are really more about the need to add more indexers and improving the settings which I’ll get to.


Now I am with Plex to get this set up.

Plex Media Server seems to working ok.
Take that back - just updated and now it seems sign in is required…that is a topic for another thread.

With an account, I am getting media to display on other devices. Went into this w/the notion Plex could be used without an account locally, on the local network. No internet, everything still works. Taking this topic up on the Plex forums.

Can’t believe most of this is up and running now. Relief setting in…


Waiting now to see how Sonarr will handle the downloaded file and what magic will/will not happen.

Yep, while there are a scant few trackers in and working, majority will not add. Same errors.

Yes, there is a tool in place and each test has been run w/o the tool in operation. Tool was in place when the few indexes were added. Turned if off just now to double check, and same error

To get so far, and still not working right…AND…discovering a possibly unfixable solution now of permissions where Sonarr will not touch the downloaded file. Many posts on this, and some have a desktop version of sonarr and granting it special permissions though that solution is not applicable to this situation…AND…that solution requires running the command line code w/every reboot.

Turns out, the IP used for Jackett changed AGAIN … to a new unused number this time. So, with the NEW IP the indexes are getting added and I went back and edited the previous indexes w/the updated IPs. They tested and saved, though not seeing a different in performance or anything.

Why is the Jacket internal IP changing?

Terms of permission problem, there isn’t a real work around (which is great to discover when you are getting closer to home base.) The plan now is to see if I can change the default download directory to a different location which is less locked down. Funny though, not seeing that option the than default location for transmission downloads.

if the tracker doesnt validate i dont think sonarr will add it. if you want to add a (currently) non working tracker you need to turn off RSS and the two search options for it, then it will save.

at some point you have to fix whatever is stopping it from working so you can enable it in sonarr though.

because docker assigns them on container start (its sort of like, or possibly is, DHCP)

its supposed to work with the container name though (like DNS) so http://jacket:9117 should work from the sonarr container but for you it doesnt (which sort of means your docker may need to be reconfigured in in some way - mine worked out of the box but im on a synology nas not a mac)

Sonarr will not add non-working indexes. What happens is the jacket IP changed…so it requires going back and updating the indexes in Sonarr w/the new IP


If the Jackett ip keeps changing (can’t get http://jacket:9117 working) ~ well, no real point in having Plex or any of these things running. Will investigate.
localhost:9117 works from the desktop browser… maybe if not permissions, some customer change needed for urls inside the container?