I noticed that ND did not grab Revenge.S03E05.720p.WEB-DL.DD5.1.H.264-KiNGS and it was posted for quite some time. I even ran a manual RSS Sync and it never picked it up.
This is all I can find in the logs:
13-10-28 16:45:32.0|Info|NzbSearchService|Searching 4 indexers for [Revenge : S03E05]
13-10-28 16:45:32.0|Trace|ConfigService|Unable to find config key 'sabusessl' defaultValue:'False'
13-10-28 16:45:32.0|Trace|ConfigService|Unable to find config key 'sabport' defaultValue:'8080'
13-10-28 16:45:32.0|Trace|ConfigService|Unable to find config key 'sabusername' defaultValue:''
13-10-28 16:45:32.0|Trace|ConfigService|Unable to find config key 'sabpassword' defaultValue:''
13-10-28 16:45:32.9|Trace|EventAggregator|Publishing CommandExecutedEvent
13-10-28 16:45:32.9|Trace|EventAggregator|CommandExecutedEvent -> TaskManager
13-10-28 16:45:32.9|Trace|EventAggregator|Publishing CommandUpdatedEvent
13-10-28 16:45:33.0|Trace|EventAggregator|CommandUpdatedEvent -> CommandModule
13-10-28 16:45:33.0|Trace|CommandExecutor|Publishing BroadcastSignalRMessage
13-10-28 16:45:33.0|Trace|CommandExecutor|BroadcastSignalRMessage -> NzbDronePersistentConnection
13-10-28 16:45:33.0|Trace|EventAggregator|Publishing CommandExecutedEvent
13-10-28 16:45:33.0|Trace|EventAggregator|CommandExecutedEvent -> TaskManager
13-10-28 16:45:33.0|Trace|EventAggregator|CommandExecutedEvent <- TaskManager
13-10-28 16:45:33.0|Trace|CommandExecutor|BroadcastSignalRMessage <- NzbDronePersistentConnection [00:00:00]
13-10-28 16:45:33.0|Trace|EventAggregator|CommandUpdatedEvent <- CommandModule
13-10-28 16:45:33.0|Debug|FetchFeedService|Searching for [Revenge : S03E05]
13-10-28 16:45:33.0|Debug|FetchFeedService|Searching for [Revenge : S03E05]
13-10-28 16:45:33.0|Debug|FetchFeedService|Searching for [Revenge : S03E05]
13-10-28 16:45:33.0|Trace|TaskManager|Updating last run time for: NzbDrone.Core.Download.FailedDownloadCommand
13-10-28 16:45:33.1|Trace|EventAggregator|CommandExecutedEvent <- TaskManager
13-10-28 16:45:33.1|Trace|CommandExecutor|FailedDownloadCommand <- FailedDownloadService [00:00:02.2152039]
I also noticed this in my logs. What does this mean?
13-10-28 17:03:45.1|Trace|ConfigService|Unable to find config key ‘sabport’ defaultValue:‘8080’
hmm…it says that the release has been blacklisted on a manual search. I have no clue where it was blacklisted or what that even means. lol
New feature, means the download failed, so drone removed the failed download from SAB (to reclaim the diskspace), it would have added an event to history (in drone) as well, it also kicks off a search for another release. There are advanced options on File Management if you don’t want it to clean up SAB automatically/or search for a replacement.
I do need to add details to the events in history though.
I actually noticed this with Once Upon a Time right after this post. It downloaded and then vanished from Sab.
I have no idea what the criteria is for it failing because I downloaded it manually and watched it and there were no issues with the file.
Am I missing something?
Something is not right with this new feature. Ripper Street S02E01 was also blacklisted, so far that’s 3 shows. I don’t understand why they are failed downloads.
The only criteria drone takes into account is that it failed in SAB. Once the details around why it failed are exposed in the drone UI you can click the failed event to see exactly why it failed.
Here is the card on Trello: https://trello.com/c/BDf7Ubow/228-better-sab-integration
Failed details are blank for Once upon a a time, Ripper Street and Revenge.
I also did 7 manual RSS Syncs and it is not picking up Ripper Street. I don’t understand why it is not picking it up. As I stated above, the details page appears to be blank. If that is the right area I am looking in.
According to the logs, there doesn’t seem to be a reason for it not downloading.
13-10-28 19:06:05.3|Trace|EventAggregator|CommandUpdatedEvent <- CommandModule
13-10-28 19:06:05.3|Trace|Parser|Parsing string 'Ripper Street.2x01.Pure As The Driven.720p HDTV x264-FoV’
13-10-28 19:06:05.3|Trace|Parser|Episode Parsed. ripperstreet - S02E01
13-10-28 19:06:05.3|Trace|NzbDrone.Core.Parser.QualityParser|Trying to parse quality for Ripper Street.2x01.Pure As The Driven.720p HDTV x264-FoV
13-10-28 19:06:05.6|Trace|BlacklistSpecification|Release is blacklisted
13-10-28 19:06:05.7|Trace|NotRestrictedReleaseSpecification|Checking if release contains any restricted terms: Ripper Street.2x01.Pure As The Driven.720p HDTV x264-FoV
13-10-28 19:06:05.7|Trace|NotRestrictedReleaseSpecification|No restrictions apply, allowing: Ripper Street.2x01.Pure As The Driven.720p HDTV x264-FoV
13-10-28 19:06:05.7|Trace|AcceptableSizeSpecification|Beginning size check for: Ripper Street.2x01.Pure As The Driven.720p HDTV x264-FoV
13-10-28 19:06:05.7|Trace|AcceptableSizeSpecification|Item: Ripper Street.2x01.Pure As The Driven.720p HDTV x264-FoV, meets size constraints.
Also, if I turned off the feature, how come it still shows the following in the logs:
13-10-28 19:17:46.3|Trace|BlacklistSpecification|Release is blacklisted
Details aren’t there yet, its in the DB, but is not yet displayed:
@markus101 said:
I do need to add details to the events in history though.
13-10-28 19:06:05.6|Trace|BlacklistSpecification|Release is blacklisted - once its in the UI you’ll be able to see why, next release should contain it as I’ll be working on that later
ok, that sounds good, but in my updated post I was asking you if the feature is turned off as I have it now, then shouldn’t ND just work as it did before and just grab the release?
There isn’t an option to disable blacklisting completely, one turns off the auto search after a failure and the other stops it from removing failed downloads from SAB, but I suppose its worth while to have the option to disable blacklisting altogether, though we intend to keep it on by default.
How are you getting that many failures? I’ve been running this feature for a week and the only failures I have were ones I grabbed to test this functionality. If this is still due to your provider being slow, I would seriously consider moving.
Well, it wasn’t an issue since you integrated it in the last few days. It seems to be a problem today. I also have the RSS intervals set to 30 mins which is more that sufficient I would think.
It also grabbed Homeland’s latest episode of better quality shortly after the failed ones and that had no issue. So maybe it is not the provider.
RSS interval just sets how often it hits the indexer, its still possible that drone tries to process a release within a few minutes of it being posted.
I’ll add the option to disable blacklisting and you can sort out if you want it on or off.
I seem to be having this issue again. I sometimes see a better quality file posted so I do a manual RSS sync, but in this case it does not grab the web-dl 720p copy of Supernatural.S09E13.720p.WEB-DL.DD5.1.H.264-ECI
I see this in the logs:
14-2-5 14:45:32.5|Trace|CommandExecutor|BroadcastSignalRMessage <- NzbDronePersistentConnection [00:00:00]
14-2-5 14:45:32.5|Trace|EventAggregator|CommandUpdatedEvent <- CommandModule
14-2-5 14:45:32.5|Trace|Parser|Parsing string 'Supernatural.S09E13.720p.WEB-DL.DD5.1.H.264-ECI’
14-2-5 14:45:32.5|Trace|Parser|^(?.+?)(?:(\W|)+S?(?(?<!\d+)\d{1,2}(?!\d+))(?:(?:\-|[ex]|\W[ex]|){1,2}(?\d{2,3}(?!\d+)))+)\W?(?!\\)
14-2-5 14:45:32.5|Trace|Parser|Episode Parsed. supernatural - S09E13
14-2-5 14:45:32.5|Trace|Parser|Language parsed: English
14-2-5 14:45:32.5|Trace|NzbDrone.Core.Parser.QualityParser|Trying to parse quality for Supernatural.S09E13.720p.WEB-DL.DD5.1.H.264-ECI
14-2-5 14:45:32.5|Trace|Parser|Quality parsed: WEBDL-720p
14-2-5 14:45:32.6|Trace|Parser|Release Group parsed: ECI
14-2-5 14:45:32.9|Trace|BlacklistSpecification|Failed Download Handling is not enabled
14-2-5 14:45:33.2|Trace|CutoffSpecification|Comparing file quality with report. Existing file is HDTV-720p
14-2-5 14:45:33.2|Trace|NotRestrictedReleaseSpecification|Checking if release contains any restricted terms: Supernatural.S09E13.720p.WEB-DL.DD5.1.H.264-ECI
14-2-5 14:45:33.2|Trace|NotRestrictedReleaseSpecification|No restrictions apply, allowing: Supernatural.S09E13.720p.WEB-DL.DD5.1.H.264-ECI
14-2-5 14:45:33.2|Trace|AcceptableSizeSpecification|Beginning size check for: Supernatural.S09E13.720p.WEB-DL.DD5.1.H.264-ECI
14-2-5 14:45:33.2|Trace|AcceptableSizeSpecification|Item: Supernatural.S09E13.720p.WEB-DL.DD5.1.H.264-ECI, meets size constraints.
14-2-5 14:45:33.2|Trace|ConfigService|Unable to find config key ‘sabusessl’ defaultValue:‘False’
14-2-5 14:45:33.2|Trace|ConfigService|Unable to find config key ‘sabusername’ defaultValue:’‘
14-2-5 14:45:33.2|Trace|ConfigService|Unable to find config key ‘sabpassword’ defaultValue:’'
14-2-5 14:45:33.3|Trace|LanguageSpecification|Checking if report meets language requirements. English
14-2-5 14:45:33.3|Trace|QualityAllowedByProfileSpecification|Checking if report meets quality requirements. WEBDL-720p
14-2-5 14:45:33.3|Trace|UpgradeDiskSpecification|Comparing file quality with report. Existing file is HDTV-720p
14-2-5 14:45:33.3|Trace|HistorySpecification|Performing history status check on report
14-2-5 14:45:33.3|Trace|HistorySpecification|Checking current status of episode [5844] in history
14-2-5 14:45:33.3|Trace|RetentionSpecification|Checking if report meets retention requirements. 0
What comes after: 14-2-5 14:45:33.3|Trace|RetentionSpecification|Checking if report meets retention requirements. 0 ?
Do a manual search for that episode, it will give you the reason it was rejected, its possible thats not listed in the logs (which we should add, but need to know where it was rejected).
I did a manual search but it does not come up with a red flag next to it.
btw, this also happened with Justified S05E05 web-dl. No flag next to this one either.
Okay, there are 3 checks that would not be checked for searching, but are during the normal RSS Syncing process:
Monitored episode - If its not monitored it won’t be grabbed (if either the series or episode isn’t monitored)
Proper - ensures drone doesn’t download a proper for an old episode (the proper is for the actual file)
History - makes sure the last time this episode was grabbed (any quality) is not still downloading AND checks that its an upgrade according to history (these prevent things from being redownloaded even though they may be unsorted).
Neither of these are propers, so its not that, leaving monitored and history. If the series and episode are monitored that leaves history, meaning there is either an version in there with a better quality or its still “downloading”.
Here is an image: http://postimg.org/image/l306m8mtf/
There is only HDTV-720p in there and there is nothing downloading.
Also, please ignore the fact that it shows unmonitored. I just tried it again and same problem.
Here is an updated image:
http://postimg.org/image/l8r77pg23/
Update: I just ran a manual rss sync again, after 5 tries it finally grabbed it. I have no clue what or why this happened.
Was the episode ignored when the RSS sync was running before?
No, but I can tell you what I did. Earlier on I decided to grab the webdl720p episode manually and it downloaded it and sorted it, then I decided to try and reproduce the problem.
What I did was, I deleted the webdl720p file and then I copied the HDTV-720p file back into the series folder. After I did that and updated the series, it unmonitored that episode, this is why that 1st image showed unmonitored.
Nevertheless, it still didn’t work after the episode was monitored until I ran the manual rss at least 5 times.
Hope you understand what I am trying to say.
Shedrock