new sort_by_weight plugin#1533
new sort_by_weight plugin#1533paranoidi merged 14 commits intoFlexget:developfrom Andy2244:sort_by_weighted
Conversation
fixed dict exception
|
I think splitting The current format is weird and hackish imo. |
| field: Name of the sort field | ||
| weight: The sort weight used, values between 10-200 are good starts | ||
| weight_default: The default weight used if a sort 'field' could not be found or had a invalid entry (default is: 0) | ||
| inverse: Use inverse weighting for the field, example: Date/Age fields |
There was a problem hiding this comment.
What exactly inverse or weight_default?
There was a problem hiding this comment.
The line that I'm commenting on. Line 38.
There was a problem hiding this comment.
Inverse weighting means that the lowest result slot gets the highest score and the highest gets the lowest score. So for Age/Date fields the entries with (0 days) get the maximum weight and older entries start getting lower and lower weights.
|
|
||
| log = logging.getLogger('sort_by_weighted') | ||
|
|
||
| SUPPORTED_TYPES = ( |
There was a problem hiding this comment.
What's the point of this exactly?
There was a problem hiding this comment.
The types?
Mainly to safeguard from using unsupported fields. Sorting by string for example would need something like "similarity" between them for expected results.
| def on_task_filter(self, task, config): | ||
| # [field] = [weight, weight_default, delta, inverse, [min,max]] | ||
| settings = {} | ||
| for centry in config: |
There was a problem hiding this comment.
centry is a weird variable name imo
There was a problem hiding this comment.
aye, will be changed
…gets more confined
|
I'm happy with it at this point, so consider it for a merge. |
| 'minItems': 2 | ||
| } | ||
|
|
||
| # def on_task_start(self, task, config): |
There was a problem hiding this comment.
Comments that serve no purpose should be removed
|
I feel the schema is overly complex, but I'm not sure how to remedy that. |
|
I don't expect this plugin to-be widely used and remember you only need this at a bare minimum, which looks less scary and still delivers usable results. |
remove unused comment
|
Why is it 'sort_by_weighted' instead of 'sort_by_weight'? Could this all be combined into sort plugin. Not a huge fan of multiple plugins doing same things .. |
|
The name was just what came first to mind and coveys the idea of a 'weighted' score sort. As for combining the sorts, this would make the config schema more complex, but could be done. I simply did not feel confident enough to fiddle with a existing plugin and existing configs. |
| value = value.days | ||
| elif isinstance(value, bool): | ||
| value = int(value) | ||
| if len(settings[key]) == 6: |
| if value is None: | ||
| continue | ||
| if key not in max_values: | ||
| if len(settings[key]) == 6: |
| else: | ||
| max_value = value | ||
| else: | ||
| if len(settings[key]) == 6: |
| continue | ||
| if key not in max_values: | ||
| if len(settings[key]) == 6: | ||
| max_value = min(value, settings[key][5]) |
|
Assuming backwards compatibility it would be fine to combine this into sort. |
|
Can refactor the local settings array to a dict, to remove the magic values. I can try combining the two, but might need help with the schema. |
|
Just took a fresh look at sort_byvpkugin, not so sure about merging anymore. It seems to be very field specific .. |
|
Yes i also feel it works quite different, so might confuse usage. I'm trying to refactor the algorithm so it can work with any type that has a lt/gt comparator, mainly to support the Quality type. |
max value fixes Quality type support proper timedelta handling
fixed crash on weight calculation fixed lower defaults updated examples
|
oki, did refactor the code to technically support all types, but the weight results for types like |
| return | ||
| config = self.prepare_config(config) | ||
| log.info('sorting ´undecided´,´accepted´ entries by weight!') | ||
| log.info('sorting undecided, accepted entries by weight') |
There was a problem hiding this comment.
Seems like unnecessary logging. You would expect it to run if you've enabled it...
There was a problem hiding this comment.
I wanted to make clear that the weighting is only calculated for undecided, accepted entries, which is different to how sort_by works. It still sorts all entries at the end, but the other states get the default weight of 0.
|
Just wondering do i have to add a test for every new plugin i write, to-be accepted for a merge? So far none of my plugins have been merged yet or is there a minimum time that has to lapse without new changes? |
|
@Andy2244 Process is slow sometimes , but your contributions are greatly appreciated! Join IRC / Gitter for more hands on involvement :) Unit tests are greatly appreciated as we are going to maintain this plugin long term. Only other issue that I can spot now is the too long docstring which should not prevent merging :) Can you add some unit test and we'll get this one merged right away! It's not required but I would feel much better if it had some. |
cleanup exceptions, logging
|
Implemented suggested changes. PS: I know its bad practice, but i want to finish the Anidb lookup plugin first, before i look at the testcode for each my plugins. |
|
@Andy2244 Understandable, a lot to take in such short time. I'm merging this in. Please update the wiki page to include this plugin! :) |
Motivation for changes:
I wanted the ability to better sort the discover results, so the best release could be picked-up. Basically i wanted to weight different stats/data fields, so the filter plugins can pick the best from the top.
Detailed changes:
sort_by_weightplugin that takes multiple fields as input (at least 2)sort_by_weight_sumand sorts so the highest weight entry is on top of the listConfig usage if relevant (new plugin or updated schema):
Simple
Advanced
Example of my own 720p based movie newznab settings: