I looked but could not see a way to do this. I know under the “indexers” tab you can restrict the use of words but is there a way to do it from the quality section? If not I think it would be a good feature because certain release groups have much better quality than others. I typically prefer a 1080p web-dl to a hdtv-1080p file because of logos, encoding glitches, subtitle issues, etc. There are some release groups that have very high quality pre-air hdtv rips though that I prefer to web-dl. The main profile I use for most of my shows though will prioritize hdtv over web-dl and blu ray over hdtv. What I would like is to prioritize hdtv over web-dl only if it meets a certain condition, such as that hdtv download includes a certain word in the filename, like the name of a specific release group.
We do plan to add prioritization:
But quality will still control upgrades so you’re not going to get exactly what you want, but you could work around that using a custom script to unmonitor episodes that have the release group you prefer over WEBDL releases after the HDTV release is imported.
Just to clarify my request a little, the “indexers” tab already has global restrictions. I think “local” restrictions could also be added to the “quality” tab or maybe even for the profile. That way you could further define, for example, what an “HDTV-1080p” is by more than filesize. It would only consider it an HDTV-1080p if it meets the filesize AND contains this word or doesn’t contain that or prefers a certain word. In my case then, I would have bluray be my first choice, HDTV second, and web-dl my third choice, but it would not define a release as “HDTV” unless it contained the name of the release group I want.
Unless I’m overlooking something, I don’t think it will be a problem for upgrades, at least not how I’m envisioning it. “Preferred” words was another thing but I figured that was already being requested. Maybe there is a better way than what I am thinking though. I thought about using tags with the series but the problem with that is that it applies to all profiles and qualities so if I tell it it must contain this release group name when it downloads an HDTV it will not upgrade to the bluray if it does not also have the release group name.
The problem is this is a very specific to your use case or at least a limited number of users wanting a very specific subset of releases its not something we’re going to commit to implementing, so at this time its not something we’re considering.
No exactly what you want, but for specific series, you can just add a different profile which prefers the hdtv and has a must contain word of the release groups. The must contain preference is configured in a different tag, which you then apply to the series in combination with the new quality profile.
As mentioned, that won’t really work since the tag will apply to every quality in that profile. It will work for downloading the HDTV but it will never update to a bluray rip unless that bluray rip also has the same word.
I don’t think it’s nearly as niche as I am making it seem. Without getting too focused on the specific example I gave, the key point I’m making is that right now, the only thing the user has control of as to what defines the quality of the download, is file size. What if you want to require bluray rips to be x265 but are fine with x264 on web-dl or tv rips? Or you want your web-dls or hdtv rips to be mp4 files for your mobile device but you still want them to upgrade to mkv bluray later on? My specific use case aside, there is no way way to get that kind of granularity and flexibility on a quality level, only globally or by series.
Perhaps a better solution than what I proposed earlier will help better explain it as well: being able to add tags to the qualities in an individual profile. That would provide the same kind of granularity for profiles/qualities that tags already provide on a global level and series level. I think that would increase the flexibility to far more than my example.
The problem from my perspective is less about it being niche (though that plays a big role) is how would the typical user use it. Flexibility is a good thing, except when you have too much and only a few people understand how it works.
-
If I can set restrictions, set a tag and apply that to a series its pretty clear (or at least I hope it is), how that restriction will be applied, it will apply to everything for that series.
-
If I apply that same tag to a quality and a series, but not to a restriction, what happens? Probably nothing, but in the world where everything links to back to a series I could draw the line that it means that quality will only work for series with that tag, which would be super confusing in practice, but logically make sense.
-
If I applied a tag to a restriction, a series and a quality, I’d have a similarly awkward scenario where I’m not really sure whats going to happen without testing and the result would be that a series restrictions would work like they do now and quality would be further limited.
I do see value in what you’re proposing, but I don’t think the value outweighs the complication or in the tagless version that the implementation time would be valued by enough people and not cause confusion for people (I can already hear the request for restrictions per quality within a profile).
You’re making it too complicated. Just use a separate profile for the shows where you want HDTV rips instead of WEB-DL. Works perfectly. I get the great DIMENSION rips for the shows they cap and the WEB-DLs for the rest.
Yes, you have to be a little bit more aware (like noticing that DIMENSION started capping a lot more shows at the mid-season break), but it’s not that big a deal.
Frito, that’s not going to work for the scenarios I’ve described and I’ve already explained why.
markus101, I’m a little confused on the terminology you are using. What do you mean by “restriction” when you say “If I apply that same tag to a quality and a series, but not to a restriction” and “If I applied a tag to a restriction, a series and a quality”? You talk about applying a tag to a restriction but my understanding is it’s the other way around, you apply restriction to a tag.
After thinking about those comments, I think I might just have a fundamental misunderstanding of tags, or at least only a partial understanding. I thought the purpose of tags was to link restrictions to objects but it seems obvious now they can be used for more than that, such as tagging a series as a comedy. Is that right? I think I understand your points regarding how confusing tagging could be. I was just thinking of tags since it would be easier to just expand the usage of something that already exists instead of implementing something entirely new. But know that I know that a tag can exists independently from a restriction, I can see how that would not be ideal. What about adding restrictions (must contain, must not contain, prefer) in profiles that are not tied to the tag system or indexer based restrictions? What would you consider the need/complication trade-off there?
Also,I hope you don’t think I’m trying to be argumentative until I get my way, I’m not. I’m just trying to discuss it to better my understanding in the hopes that I can explain my situation and make a proposition that is beneficial without introducing unneeded complication. Perhaps in the future I should try to spend more time thinking about and articulating my issue and possible solutions prior to bringing it to forum, instead of just explaining my specific problem and hoping someone has an idea.
A tag is a field on a restriction (setup on the indexers settings page) since a restriction can not have a tag (the same way a series can not have a tag) the tag is applied to the restriction. At least thats how I see it.
Tags are a way to link a series (or group of series) to an object, a restriction, a delay profile or a connection (notification) at this time, perhaps more later. The idea is that if the object doesn’t have a tag it applies to all series, if it does have a tag it applies only to series with that same tag. What we don’t want to do is have tags become object to object so things get really messy, one example is whether a torrent client and a public/private indexer can be used, it could be done with tags, but then tags take on power of their own and they lose the central connection of being linked to a series.
The complication is people will do something dumb, like add 720p to SDTV or Bluray on HDTV 720p and then get frustrated that it doesn’t work, now I know the first thought is no one would ever do that, but we’ve seen some really weird things done in the past, people already reverse the order of qualities willy-nilly and then get confused when nothing upgrades or it upgrades to the wrong thing. I also think not that many people would use it, its a pretty strict feature and would require some understanding of how it works and a want for ultimate control.
Not at all, one of the biggest challenges we have is figuring out what we should add and what we shouldn’t when things get very specific and its not something we see a lot of people using we generally won’t implement it, we don’t have the manpower to add every feature requested and support becomes big thing, if its likely to cause issues it becomes a support nightmare and that means we can’t work on new features and don’t get anything new added.
Your idea makes sense, I understand what you want to accomplish, its just not something we can consider implementing at this time and we don’t want to give a false sense that it will be added. Saying no is hard, but saying yes and never doing it is no better.
Have you considered a custom script that executes after import? If its the correct quality and has the correct release group you could unmonitor the episode and take care of the problem like that.
For the very specific scenario you initially described where you want a certain release group’s caps for a certain specified reason, it absolutely does work. I’ve been doing it for at least a year now. For your other scenarios regarding excluding x265 and whatnot, of course it won’t work. I was only talking about what you described in your first post:
You can make THAT work exactly the way I described. Your other theoreticals could probably be worked out with some creative thinking as well.
@Frito - I agree with you to an extent, but while filtering DIMENTION or nTB for the pre-air HDTV which are better than WEB-DL will absolutely work for HDTV download, it then becomes difficult to grab the BluRay when it comes out because of the tag restrictions.
Who said anything about filtering for those particular release groups? The tags don’t work that way anyway, remember? That’s the whole point of this thread lol
My profile for the shows where I want the HDTV releases has Blu-ray at the top then HDTV below it. No tags are involved. All of the other shows have Blu-ray at the top then WEB-DL below it. Both profiles have a fallback quality in third place “just in case.” I remember DIMENSION missed a couple episodes of Complications, so I had to settle for the WEB-DL. Otherwise, it has worked flawlessly. Obviously I can’t force a release group to cap a show if they had some sort of issue that week 
[quote=“Frito, post:12, topic:9918, full:true”]
For the very specific scenario you initially described where you want a certain release group’s caps for a certain specified reason, it absolutely does work. I’ve been doing it for at least a year now. For your other scenarios regarding excluding x265 and whatnot, of course it won’t work. I was only talking about what you described in your first post:[/quote]
Speaking from a programmatic standpoint, those scenarios are the same.
It won’t work, not without manual intervention, which would defeat the purpose of having an automated system.
In my view, web-dl trumps hdtv except when hdtv is DIMENSION. If I just make a separate profile where HDTV trumps web-dl as you described then I would have to keep track of which shows DIMENSION caps as well as when they quit capping a show. Which mean I would constantly be switching from hdtv to web-dl, and have to stay informed on when they start and stop capping something. For instance, DIMENSION quit capping Better Call Saul, so I had to switch back to web-dl. They started capping Modern Family for part of a season so I had to go and change it to start getting those. Then they stopped capping them and I had to go and change things again. I’ve already been using your solution and it’s a pain in the ass. Like I said, it doesn’t work for the situation I’ve described.
I haven’t. I knew custom scripts were in the works a while ago. I was actually one of the people giving feedback on it and such. I just haven’t been following it lately.
That might be useful for what I’m trying to do. What do these do?:
EpisodeFile_Quality
EpisodeFile_QualityVersion
Perhaps I can write a script where if the release group doesn’t equal X then it tells Sonarr to grab another quality? Do you think that’s possible if I have the script interact via the API?
Oh, the horrors. Two shows made you put forth a ridiculously miniscule amount of effort…what, three times? But that translates to “constantly…switching from hdtv to web-dl”. I’ll be sure to share your stories of hardship and suffering with the folks down at the food bank
I have about two dozen current shows in my 1080p DIMENSION profile, and there have been zero problems. Like I mentioned already, DIMENSION missed a few episodes of Complications last summer, but the fallback in my profile grabbed the WEB-DL without any intervention on my part.
I routinely visit other sites where shows and movies are posted, so it’s not a huge chore to be aware of what DIMENSION caps, so I suppose you have a point there regarding your goal of attaining ultimate automation/laziness.
Why are you continuing to post if you have nothing constructive to contribute? The entire purpose of my post is to find a way to avoid doing the exact thing you are describing. Your solution works for you, that’s great. It doesn’t work in my situation because it doesn’t work without manual intervention. I only gave those two examples but your “solution” would mean I would have to check every show on a regular basis in case they stop capping a show, they start capping the show again, or they start capping a new show they have never capped before. Not a problem for you, great. But I’m not keen and having to babysit an automated system. I get enough of that at work and it’s just counter-intuitive.
Anyway, the issue has reached it’s conclusion as markus101 has heard my plea and made a decision and given me an alternate option.