Sonarr version (exact version): 3.0.1.467 OS: Windows Server 2019 Debug logs:
single indexer enabled (nyaa.si via Jackett, RSS disabled, Automatic Search disabled, Interactive Search Enabled) the relevant bits start at 12:42:49. This is when I enabled debug logging and started a search. https://hastebin.com/dihejuliyo.rb Description of issue:
Sonarr takes a ridiculously long time to search indexers. It can take ~15 minutes or more (haven’t timed it exactly) to do one search (for a season, or episode, doesn’t matter).
I’ve tried disabling all indexers and only testing one at a time to see if there was one in particular that was slowing it down, but this is happening on every single indexer I try individually.
I’m using Jackett for the API integration for the trackers. I’ve tried searching from Jackett itself and the search speed is normal, pretty quick, and that’s searching all the trackers added there.
I’ve also tried doing a clean reinstall of Jackett to really test if Jackett was the issue. The problem persisted after the Jackett clean install.
So basically, I’m pretty sure it’s not an issue with Jackett, and rather is a problem with Sonarr querying the indexers.
My bad on the logs. I thought the debug logs would be in place of the standard ones, not separate files. I’ve uploaded all the logs from my most recent test and they’re linked below:
[edit… apparently I can’t add more than 10 links in a post, so sonarr.txt and the debug logs are here, trace will be in another reply]
This test was done with all my Jackett indexers enabled. I did a manual interactive search for Attack on Titan Season 2. I forgot to take down the exact start and end times, but it ran for ~30 minutes or so before I cancelled it by clicking the ‘x’ on the Interactive Search window.
To answer your question about indexers not through Jackett - I didn’t, but I added one for testing. It’s still slow. A bit faster than the other ones I was testing, but it still took ~5-10 minutes to return results. That test isn’t included in the above logs I don’t think, but I can do a test with it and include logs if it would help, just let me know.
I’m seeing hundreds of results including things that shouldn’t be returned such as movies and unrelated results, it looks like you’re getting garbage results from your indexers and Sonarr is forced to go through it all coupled with what looks like a search for an entire anime season which will result in a search for every episode since season packs aren’t common and batches are of unknown size.
Are you doing a full season search for an anime series?
This is coming down to Jackett and/or the indexer, nothing we can do on Sonarr’s side to improve this behaviour.
I did a manual search of a non-anime, single-episode, using only a well-maintained (not free) tracker (but still through Jackett) and it was actually pretty quick (no results, but whatever, it still returned quickly).
I’m still a little confused why Sonarr takes so much longer on the search than doing the same search directly on Jackett. For example, I search for something on Jackett (searching across all my trackers it has) and it takes maybe 30 seconds to return. The same search on Sonarr takes upwards of 30 minutes. Just for my curiosity, what is it that Sonarr is doing that takes exponentially longer to finish a search?
If you search for a single episode of anything it should be pretty quick, but it’ll depend on different factors, whether there are multiple aliases (which means multiple searches) and the time it takes to process all the results.
Like I said in your logs it looks like you’re searching for an entire anime season in Sonarr which means the total number of searches it needs to execute is number of episodes * number of aliases for the series + season. After that it needs to parse and process every single result returned.
I typically have been searching in Jackett using the series name + season + season number, so like for example “Attack on Titan Season 2” and it comes back pretty quick, but yeah there’s a bunch of results so that makes sense that it needs to process them.
And it makes sense that anime goes and searches by individual episodes, then the jp and en aliases for the series, and for each of those there’s probably a bunch of results it’s got to sift through, especially so for a whole series.
Thanks for all the info, it’s helped clear up a bunch of confusion. I need to adjust my trackers that I use for anime so they’re more efficient, or just do it manually in the meantime until I find something I like.
Also, canceling an interactive search does not short-circuit the background processes associated with it, And Sonarr only runs up to 3 tasks simultaneously, anything beyond that is queued.
So, if you run an automatic search for season 17 of One Piece (118 episodes), an RSS run kicks off, and you run an interactive search for Season 13 (100 episodes) and then immediately cancel it because you meant to run it on Season 14, the RSS and both searches are still running.
This means everything including internal tasks are queuing up, so when you run the interactive search on Season 14, It has to sit and wait for a slot to be freed up, which could take a while since the RSS and 2 searches are all competing for resources and all talking to the same Indexers (or in this case, all talking to jackett, which is running all of the searches for you), and when it does get a slot (because the RSS finished), it is now competing with the other two searches.
(Side note: Running an automatic search for the entire series of One Piece through 45 indexers can take days.–Yes, I know that is a lot of indexers, I only have a handful that are on RSS, and some really old shows are hard to find).
A point of clarification, unlike automatic searches, interactive search does not use background threads, it’s through a normal XHR from the browser to the web server. I’m not sure how closing it is handled by the backend though.
