How soon does Sonarr do another search for the episodes that did not meet their quality cutoff yet?
I tried manually searching for some older “cutoff unmet” episodes and I was surprised that there were hits and they were sent to SAB as of the moment. If Sonarr was constantly checking for higher quality copies of this episodes, I would expect that when I do a manual search nothing will be found. Does that make sense?
This may have to do something with this problem but if you check the screenshot above, the episode was downloaded as WEBDL-1080p but was imported as HDTV-720p. Why is this so?
It doesnt auto search for quality upgrades, it only reads the RSS feeds automatically, so if a quality upgrade appears in the RSS it will grab it, But. if you shutdown your sonarr for a long period, it is possible you will miss out on quality upgrades if it arrived in the RSS during the time it was shutdown
Oh ok, that makes sense. Is this done to avoid too much traffic? And is there a way to search for all “cutoff unmet” episodes? You can tick the uppermost checkbox but it only selects all episodes in a page. I ahve 10 pages of these episodes.
If that’s the case, it seems that the picture I’ve posted is a different issue altogether. Can the mod transfer that to a new thread?
SAB is trimming file names down to a certain limit, which means Sonarr can’t get the quality from the filename, only the file extension. If you download to a shorter path, C:\Downloads instead of the current path then you can disable the trimming and it won’t trip Sonarr up.
Of course! Why didn’t I notice that. I configured SAB to make the folder_max_length be 50 only (instead of the default of 128) because it was also having problems with CouchPotato. I’ll move my main download folder anyway and let Sonarr and CouchPotato take care of the tidying of things.
Would that be the same as searching for all wanted episodes?
Are RSS feeds fed on a daily basis? Does that mean that every RSS Sync will only have episodes for a single day? If so, it isn’t the same as searching for all “cutoff unmet” or “missing” wanted episodes then.
No, not the same at all. Searching asks for a particular episode (searching for all missing does a search for each missing episode), RSS just watches to see if a wanted episode appears and then will grab it.
They are typically updated every 15 minutes (depends on the indexer) and contain the last 100 items (in most cases), so you’re only ever going to see the last 100 items, if it takes a day to roll over 100 you get a full days worth, but typically it rolls over in a few hours.
Got it. Why isn’t there a button to search all cutoff unmet episodes though? I have 10 pages of cutoff unmet episodes and I have to tick the box on the upper left corner for every page to search them all.
Because we didn’t see a need to add it, not sure if we will as we’re not really fond of search all missing either (it can be heavy on indexers as it needs to make potentially thousands of API calls).
Let me pitch my case:
I watch most episodes downloaded within ~1 week.
After that, it’s a waste of bandwidth and diskspace to download a higher resolution.
Would it be hard to add an option to the “quality profile” that specifies a max time to search for quality upgrades?
(And while wishing, in a dreamworld there would be integrations into plex/xbmc/trakt(?), and the ability to stop quality-upgrades for watched episodes… Hehe I sound just like my clients at work :P)
Its not whether its hard or not, its whether it provides meaningful value to people and I don’t see a lot of value with this, inevitably you’ll have releases just outside of the cutoff that are missed and it will bring up questions and it seems like option bloat when we could do it right and base it off of watched status.
This has been requested and something we’re considering:
I fixed it myself, now I just have to figure out if it’s possible to keep my own fork, with my changes, updated with your releases. No idea how much headache that will cause.
Really like your codebase!
Thanks for your time/input!
I hope I choosed the best approach by adding a DecisionSpecification?
(and yeah, I check against the file date, not the air date)