Release Rejected
Are these settings i need to add to shows that i never noticed before?
I manually added them all after posting, but i will post the current log anyways as it shows similar errors.
https://pastebin.com/Ymj9TQW3 It was to much to paste the entire log, but it is the same thing repeated over and over and over (this was simply from 1 series but a majority are doing it now).
If there is a setting i need to change, just let me know.
You have a preferred word term in a release profile that has no value for the term (or it’s only spaces). You’ll need to remove that.
I’ll add a guard to prevent against that being saved.
Yes, that explains why it started recently.
So here is the backstory on that. I asked about prioritizing indexers. The response i got was a vague one at best and it was to utilize release profiles. So i did and my attempt was to simply add the indexers and give the ones i want as priority a higher score & leave everything else blank so it would work for everything and only look at the indexer for basing the score on. I assumed this would mean if the release is found in the rss from multiple indexers it would grab the one from the higher score. I guess this isn’t right and it cant be used in that manner?
Since there wont be any support for prioritizing indexers i am simply trying to find a hackish way to do it. A lot of sites base things on ratio and when some indexers have a lot higher ratio and a lot more padding to play with, it is extremely helpful to prioritize in this manner.
If anything it’d be a hack, but leaving it blank won’t work, you’d want to match on . or something common in the release name.
Says who? It’s not a priority and we need to figure out how it fits into the overall prioritization (quality, language, preferred words all have their own prioritization to consider).
I’m fine with a hack. I can try . or .* if there is a chance it’ll work.
Being told it isn’t a priority and also being told “i dont feel like talking about this” kinda speaks volumes towards a 7 year old request.
Edit: Dont take that wrong, you guys pick & choose what you see fit as features worth adding and when to add them. You also see fit on prioritizing tickets. I have no issue with that, you’re the devs. Was simply answering the question.
Taloth wasn’t implying he didn’t want to have a conversation about it at all, but he was in the middle of something else and “now” literally meant right now.
We discussed it a bit after you talked to him about it, without having a way to customize how things are ordered for prioritization there isn’t an easy fix, which turns something seemingly small into a large undertaking.
So if there is a priority option in the release profiles (or in the indexer page specifically for that matter) that allows for sorting them numerically (by a weight) then you have the priority part.
The feed that pulls from all of the indexers goes into an array of sorts i guess? If so can you not group by indexer and sort by the weight? This would process them in the order of indexer picked by the user… I guess the only reason this wouldn’t work is if the rss list is not a single array of everything found that can be sorted/manipulated in that manner? Guess it couldn’t be that simple or it wouldn’t be 7 years old lol… Wishful thinking i guess haha.
I just used “p” as the term since most everything has the quality in the name. As of the last dozen grabs that seems to be working and it is grabbing from the ones i want it to first. Hack’ish or not i’m good with a solution that works more often than not.
There are lots of things to consider.
Quality and Language are locked, though grouping all qualities and having a single language would eliminate their weight. Preferred words already has an impact on season packs so it’s already a balancing act.
rssResults = [
{name: some_name1, quality: some_quality, language: some_language, indexer: some_indexer1, points: 10},
{name: some_name1, quality: some_quality, language: some_language, indexer: some_indexer2, points: 10},
{name: some_name2, quality: some_quality, language: some_language, indexer: some_indexer1, points: 10},
{name: some_name2, quality: some_quality, language: some_language, indexer: some_indexer2, points: 10},
{name: some_name2, quality: some_quality, language: some_language, indexer: some_indexer3, points: 20},
]
Lets assume some_name1 is a tie for points, quality (both are 720), language (both are english), etc and this is where the indexer priority would come into play. It could/should be the last thing checked when there are multiple results for the same file with the same compare outcome. If there is a result such as some_name2 that has a higher score from an indexer that isn’t the priorty it would still grab that one because the other factors put it higher.
I guess in my head this would work as the indexer priority only comes into play if the release is a “tie” as far as all the other factors are concerned.
Sonic.The.Hedgehog.2020.1080p.WEB-DL.H264.AC3-EVO is found on 5 indexers and show up in the rss for each one, so it is in there 5 times? or does it not do it that way and only adds 1 release to the stack per name even if it is found on multiple indexers? If it is in there 5 times, then this logic should work. After the compare balancing act is done and it determines the score for the release it then looks to see which of the indexers has it and pulls from the highest preferred one first.
Maybe i just cant put my thoughts to words well enough… i dunno
For the exact same release things are pretty easy, but if you take seeders or size into account it gets complicated. Parts of it are easy, parts of it are hard, making it hard.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.