Sonarr 3.0.6.1355:
Mono 6.12.0:
Manjaro:
https://wormhole.app/XnL0b#b4Ev_7cgrcUlSpYRpPY4rw:
Today the first 3 episodes of Invasion (2021) dropped and Sonarr grabbed E01 and E03, but not E02. I used Sonarr to search for it and found plenty of copies and plenty that meet all settings I have in Sonarr so E02 should of been grabbed. The one I manually grabbed that met all my setting was uploaded over 6 hours ago so I have no idea why it wasn’t also automatically grabbed like E01 and E03.
You’ll need to look at debug logs, the info logs you linked won’t tell you why those releases were rejected.
And if I change it to debug I’ll have to wait and see if it happens again with another show. The way the logging is done is a true joke, unfortunately Sonarr and Raddar aren’t the only programs that have this screwed up.
95% sure poor release naming is the cause
https://www.reddit.com/r/sonarr/comments/qeahmm/new_series_without_a_year_is_there_any_way_around/
It found the items just fine as stated above. when I did a manual search I chose one for E02 that was named exactly as E01 and E03 were, so no that was not the issue. Then you have the fact that at least 8 did not have the red circle with with the ! in the middle of it and plenty of seeds. Since E01 and E03 were grabbed with in minutes of each other according to my torrent client it’s reasonable to assume that Sonarr should of grabbed E02 at the same time.
you’ve provided no logs of of anything as requested several times.
Also S=>E I assume some typos?
It is not reasonable to assume that Sonarr should grab anything without proof - It is also possible that the releases were not on your RSS feed of newly added releases to your indexers and thus would never be magically grabbed. This is frequently caused by flakey indexers or several of the common problems noted on the troubleshooting article.
First logs weren’t requested. It was stated that the logs would be needed. Second as I clearly stated there is no point in the debug logs since I would have to wait to see if it happens again, which I pointed out in my second post. Lastly why didn’t you mention this “It is also possible that the releases were not on your RSS feed of newly added releases to your indexer”? Yes I made typos but I searched for the Episode from Sonarr’s calendar which would have it as S01E02.
I’ll set Sonarr to debug and give it a week to see if it happens again.
Both the forum post template and Markus’s comment explicitly noted that logs are needed and info logs - as the template notes - are not for troubleshooting. At minimum debug are needed.
Need to fix the logging method. Need to have it where everything is logged at the same time instead of 3 different logs. Love how you deliberately ignored the rest of that post. I’ll deal with markus101 from now on, so don’t bother replying to me again.
its typically due to not being in the RSS feed - the only place in which sonarr looks for things to download.
just because it was in a manual search that doesnt mean it was in the RSS feed.
you may not have that indexer set for RSS (although i presume you do)
you may have it set for a specific number of seeders so it might not have met the requirements you had set at the time it was seen.
if it was in the RSS feed and sonarr rejected it then that would be in the (debug) logs
the logging works fine. set it to debug and leave it there.
whether debug should be the default or not could be up for debate but the vast majority of users dont require it.
while there are a group of log files for each level of logging only one is active (as far as i know), the one youre currently set to.
if you have it set to info then only the info logs are updated. if you have debug logs then those are from the last time you had the logging set to debug.
the timestamps should show what logs are current.
Dude I know how it works and that’s pretty clear from my above post.
[quote=“rhom, post:11, topic:29002”]
just because it was in a manual search that doesnt mean it was in the RSS feed.[/quote]
I’m thinking like above this is the likely culprit. I appreciated the info.
This is false.
Info creates regular log files
Debug creates debug log files with debug+info and has no impact on info log files
Trace creates trace log files with trace+debug+info and has no impact on info log files nor debug log files
actually its not, you just read it wrong.
did i mention the content of the files anywhere? no i did not.
you basically said the same thing i did, you just added more info about the content of the files as well.
was it false to say that if the log level is set to info then only the info log files will have data written to them? that the debug and trace log files will still be there (if you had previously set debug or trace) but they would not be written to? because if it was then your reply is also false.
If I set it for trace is there any added impact on the system? Any I should be concerned about that is?
Unless you’re running it on a potato or like a PI2 with no storage
Not at all
OK cool, thanks I’ll set it for that then.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.