Help understanding why Sonarr is not picking up automatically an episode

Sonarr version (exact version): Sonarr Ver. 2.0.0.5054
Mono version (if Sonarr is not running on Windows): Not sure how to check that in docker.
OS: Docker (Linux)
((Debug logs)):
Description of issue: Sonar is running 24x7 sync every 15m. This is happening for few episodes, most of them are being picked up automatically. In this case (Wisdom of the Crowd S01E07) was red in the calendar (episode was from Sunday). I did a manual search and saw that one file that covered my tag (hevc) was available since 8h ago. I did an automatic search and it grabbed it with no issues but for some reason is not doing it on its own.

In the debug log of the last few hours I see that has been searching but the files were not hevc so it ignored them which is fine. What could be the reason that didn’t see the few hevc releases available? This means that all the indexers were down at the time these releases were available and for an extended amount of time?

Any help will be appreciated.

logs here: https://paste.ee/p/ph5PB1

Checking other comments it seems Sonarr gets the last 100 entries of each indexer. Potentially this means that if there are more than 100 entries every 15 min I could be missing a ton of episodes??. Does this makes sense?

Seeing, page not found.

We’ll need to see ((debug logs)) that show the release you expected to be grabbed in the RSS feed. If you didn’t have debug logging on, enable it now. If you did and that release never showed up in the logs, Sonarr never saw it, which could indicate an issue with the indexer.

It could, but 100 records in 15 minutes is quite rare and Sonarr will page back to the last release if paging is supported on the indexer’s RSS feed.

Thanks for responding. Sorry correct link is: https://paste.ee/p/ph5PB

Please bear with me: I just did a manual search and x265 releases (actually the same one) were available on 2 different indexers as follows:

Indexer 1: 24h ago twice
Indexer:2: 38h ago and 27h ago

That’s why I find very unlikely that was missed or that both indexers had issues. I just want to understand why and if there is anything I can do to avoid these situations.

I actually found a similar case with Travelers S02E05 also looking for x265. If I do a manual search i see 3 options:

Indexer 1: 5.7h and 80m ago
Indexer:2: 6h ago
–> I have the screenshot if needed.

The main log is here: https://paste.ee/p/335KA#MsNus0hMvDAHmv7xiCeUNSxumEAaKDMT

The debug logs seems to be covering just less than an hour and there is a bunch not sure if I should upload all of them or if there is a better way.

Thanks again.

If the logs only cover the last hour, they won’t be much use, but the 50 debug log files should last more than an hour in most cases. The info log isn’t useful to troubleshoot here.

Ok got into my docker instance and grabbed all the logs. Found this below related with the issue with the Travelers Series:

17-11-14 18:25:04.9|Debug|Parser|Episode Parsed. Travelers - S02E05
17-11-14 18:25:04.9|Debug|Parser|Language parsed: English
17-11-14 18:25:04.9|Debug|QualityParser|Trying to parse quality for Travelers.S02E05.720p.HDTV.2CH.x265.HEVC-PSA.mkv
17-11-14 18:25:04.9|Debug|Parser|Quality parsed: HDTV-720p v1
17-11-14 18:25:04.9|Debug|Parser|Release Group parsed: PSA
17-11-14 18:25:04.9|Debug|AcceptableSizeSpecification|Beginning size check for: Travelers.S02E05.720p.HDTV.2CH.x265.HEVC-PSA.mkv
17-11-14 18:25:04.9|Debug|AcceptableSizeSpecification|Item: Travelers.S02E05.720p.HDTV.2CH.x265.HEVC-PSA.mkv, meets size constraints.
17-11-14 18:25:04.9|Debug|LanguageSpecification|Checking if report meets language requirements. English
17-11-14 18:25:04.9|Debug|ReleaseRestrictionsSpecification|Checking if release meets restrictions: Travelers.S02E05.720p.HDTV.2CH.x265.HEVC-PSA.mkv
17-11-14 18:25:04.9|Debug|ReleaseRestrictionsSpecification|[Travelers.S02E05.720p.HDTV.2CH.x265.HEVC-PSA.mkv] No restrictions apply, allowing
17-11-14 18:25:04.9|Debug|QualityAllowedByProfileSpecification|Checking if report meets quality requirements. HDTV-720p v1
17-11-14 18:25:04.9|Debug|MinimumAgeSpecification|Not checking minimum age requirement for non-usenet report
17-11-14 18:25:04.9|Debug|RetentionSpecification|Not checking retention requirement for non-usenet report
17-11-14 18:25:05.0|Debug|TorrentSeedingSpecification|Not enough seeders: 0. Minimum seeders: 1
17-11-14 18:25:05.0|Debug|DelaySpecification|Profile does not require a waiting period before download for Torrent.
17-11-14 18:25:05.0|Debug|HistorySpecification|Performing history status check on report
17-11-14 18:25:05.0|Debug|HistorySpecification|Checking current status of episode [258] in history
17-11-14 18:25:05.0|Debug|DownloadDecisionMaker|Release rejected for the following reasons: [Permanent] Not enough seeders: 0. Minimum seeders: 1

This is 3:25pm EST and I have the manual search screenshot taken at 3:18pm EST where it shows me the following.

Obviously this is not consistent with what the indexer is showing also the other release from “MeGusta” is not listed.

What could be the reason of the discrepancy?

Debug log in here: https://paste.ee/p/dZu10

The seeding count is going to change, especially early on.

Not listed in the logs before the search? Then Sonarr never saw it on the RSS feed, which means your indexer either didn’t publish it on the feed or it was missed for some other reason. Either the indexer can’t show enough results and the RSS sync interval is too high or something else prevented it. How many results Sonarr gets from an indexer will depend on the indexer and in this case Jackett, since Jackett is the middle man here.

Ok, got it but if the RSS sync is running every 15m why after 80m that the release has been posted is not updating the seed count. Is it 80m normal? Is is anything that could be done to show “live” data?

BTW - I just changed from Sickrage and Sonarr is kicking ass. Thanks a lot for developing / maintaining this app.

The seed count comes from the indexer, a live seed count likely adds a lot of load on the indexer. I can’t say why after 80 minutes it’s still showing no seeders.

You can specify 0 as the minimum, but that could cause a search for an old episode to be grabbed as well.

That’s exactly what i don’t get. My screenshot is showing at that time what is the seed count in the indexer (s=19 - l=18) but Sonarr is showing s=0. This means, according with my understanding of how Sonarr works (that could be wrong :slight_smile: ), that this was updated in the last 15m or less and that’s why Sonarr didn’t get it (yet)?. I found very unlikely that in the last 15m or less the seed count went from 0 to 19 but I guess it could be the case.

This is also means that in the next RSS sync (next 15m or less) Sonarr would have updated it and grabbed the release.

I guess the timing could be off if something was wrong with that indexer during this period of time. One thing that could reduce this cases would be to add more indexers hoping that this release(s) are available in more than 1. In this case 1 release was not picked up by some reason and the other was not grabbed due to the seed count.

Can you please confirm that my understanding is correct?

That’s very possible, especially when the indexer likely gets peers in intervals, not constantly updating.

If the item is still in the RSS feed, then yes it would get the updated count and process the release again.

Ok. Bottom line, is there anything I can do to reduce these scenarios?

Thanks for your help and time.

It really comes down to having all the results from indexers show up on the feed which will come down to the number of results the indexer returns in a single request, which can be as low as 25 (that I’ve seen) up to 100. The better indexers also support paging of the RSS feed so Sonarr can attempt to get release it may have missed.

More indexers may help, but they’d need to be better indexers overall. Reducing the RSS sync time to 10 minutes may also help a bit (less of a chance for things to be missed and for Sonarr to see it multiple times).

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.