I have Prefer Usenet set.
I have Usenet Delay set to 5 minutes.
I have Minimum Age set to 40 minutes.
I have RSS Sync Interval set to 15 minutes.
I don’t have any series with explicit profiles.
Despite all of this, Sonnar consistantly lists for USENET grabs on the calendar view that ‘Release will be processed in X Hours’ with X equal to 2 to 3 hours after when it first finds a release. It doesn’t end up grabbing them until after that time has passed, and as such most releases are 3 hours old before it grabs them.
As far as I can tell from my settings, the oldest a release should be before being grabbed is an hour.
The 5 minute delay on usenet is pointless in this case since the minimum age is set to 40 minutes it will always wait 40 minutes to grab.
Longer delays could be caused by the following:
Another delay profile is taking precedence
Indexer reports the wrong time (in the future), so Sonarr needs to wait longer
The time on the system running Sonarr is wrong
Please post a screenshot of all the delay profiles setup in Sonarr (a shot of the summary is sufficient).
Which indexer(s) are you using?
Double check your system time.
Well I just noticed that my storage server didn’t switch with daylight savings last time, so it was an hour behind. It would seem that could be at least some of the problem. I have fixed it.
I would post a screenshot of my delay profiles setup, but I don’t have any delay profiles other than the default one.
A show just aired (1.5 hours ago), It says it will be processed in 3 hours. I ran a manual search for it just now, and there are 3 different NZB’s found at the at the highest quality currently available (720p HDTV), none of them show as rejected, and the ages of them are from 63.1 and 70.4 minutes old.
I restarted my PC after changing my clock just to make sure everything was cogent with the time change.
The pending release it has selected is from one of these: OZNZB, Usenet Crawler, or NZBGeek. I’m not sure how to tell which, but they all have the release with the exact same title as the one that shows pending.
What log level do I need to set, and what exactly am I looking for to help figure this out? Thanks for your help.
Either I’m confused or you are. I was attempting to tell you that my debug logs aren’t showing a rejection for time based reasons, and yet releases still aren’t being grabbed for several hours.
Here is another example, this time a release upgrade for an episode. The youngest release with this title for the episode in question in a manual search is 106 minutes, well over the 40 minimum, but it still states it won’t grab the release for 2 hours in the calendar. This as far as I can tell are the log portions I should be looking at to determine why it’s waiting so long to grab items, but it’s not showing any rejection for the releases, it just isn’t grabbing them until several hours after it meets the minimum time requirement.
15-8-4 00:00:23.4|Debug|Parser|Parsing string 'Removed'
15-8-4 00:00:23.4|Debug|Parser|Episode Parsed. Removed
15-8-4 00:00:23.4|Debug|Parser|Language parsed: English
15-8-4 00:00:23.4|Debug|NzbDrone.Core.Parser.QualityParser|Trying to parse quality for Removed
15-8-4 00:00:23.4|Debug|Parser|Quality parsed: HDTV-720p v1
15-8-4 00:00:23.4|Debug|Parser|Release Group parsed: Removed
15-8-4 00:00:23.4|Debug|AcceptableSizeSpecification|Beginning size check for: Removed
15-8-4 00:00:23.4|Debug|AcceptableSizeSpecification|Item: Removed, meets size constraints.
15-8-4 00:00:23.4|Debug|CutoffSpecification|Comparing file quality with report. Existing file is SDTV v1
15-8-4 00:00:23.4|Debug|LanguageSpecification|Checking if report meets language requirements. English
15-8-4 00:00:23.4|Debug|ReleaseRestrictionsSpecification|Checking if release meets restrictions: Removed
15-8-4 00:00:23.4|Debug|ReleaseRestrictionsSpecification|[Removed] No restrictions apply, allowing
15-8-4 00:00:23.4|Debug|QualityAllowedByProfileSpecification|Checking if report meets quality requirements. HDTV-720p v1
15-8-4 00:00:23.4|Debug|MinimumAgeSpecification|Checking if report meets minimum age requirements. 90.4080682966667
15-8-4 00:00:23.4|Debug|MinimumAgeSpecification|Release is 90.4080682966667 minutes old, greater than minimum age of 40 minutes
15-8-4 00:00:23.4|Debug|RetentionSpecification|Checking if report meets retention requirements. 0
15-8-4 00:00:23.4|Debug|HistorySpecification|Comparing history quality with report. History is SDTV v1
15-8-4 00:00:23.4|Debug|UpgradeDiskSpecification|Comparing file quality with report. Existing file is SDTV v1
There is no rejection string in the cases that shown in the logs. The very next line in each case is the next release being parsed. I’ll grab the logs when it happens again later.
I’ve noticed something odd. When I view tasks from Chrome on the system running Sonarr the correct time is listed for the tasks. When I view tasks from another system not running Sonarr in Chrome, all the tasks are acting like the time in Sonarr is an hour later than it should be. The time is set the same on both systems as you can see in screen shots.
Times are stored in UTC and sent to the browser as UTC (ISO-8601), if they appear off by an hour then one of the systems likely is set incorrectly and not following Daylight Savings Time (Can we get rid of DST yet?).
I don’t know of any place that will let me post the 3MB of logs that pertain to the RSS Sync, but I have them saved if you know where I can put them.
Here is what I found regarding the releases and rejections:
2 of the releases for How the Universe Works S04E04 720p HDTV were rejected because they were 20 minutes old, which is under the 40 minutes minimum, and a 3rd release said it was -98 minutes old. but being rejected for not being 40 minutes old, and waiting for a better quality release: http://pastebin.com/JMcMvDi3
-98 minutes… which indexer is that coming from? Sounds like that indexer has the wrong time set and it seems to be causing the delay to last 2+ hours instead of only 40 minutes.
I’m not sure how to tell which indexer the negative time results are coming from. I don’t see it mentioned in the log, and nothing shows up with a negative time in a manual search. I suppose next time it happens, I could disable all my NZB indexers but one at a time and run the RSS sync a single time for each indexer to see which one shows up with the negative time in the logs.
My guess would be that NZBGeek release that is an hour less than the rest, but it looks like multiple things are processing at the same time so the logs cross over all over the place.
I don’t see any case in the logs where I’d expect a grab to occur and it was rejected because it was waiting for a delay though.
