Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Torrent size as hard filtering criteria #201

Closed
satcos opened this issue Jul 13, 2020 · 2 comments · May be fixed by #211
Closed

Torrent size as hard filtering criteria #201

satcos opened this issue Jul 13, 2020 · 2 comments · May be fixed by #211

Comments

@satcos
Copy link

satcos commented Jul 13, 2020

When two filters have same filtering criteria but different size limit and action, the filter with lower priority will never be triggered. Lower priority filter will be triggered only after the higher one hitting the count limit.

This also happens if higher priority filter is narrow and lower priority one is wider filter

Example
Filter1: Movies/, Year- 2019 and 2020, Size 15GB to 30GB
Filter2: Movies/
, Year- 2000 to 2020, Size 5GB to 10GB

A torrent of Movies/*, Year 2020, Size 7.5GB should trigger Filter 2 but this is not happening.

Need to fix this issue as torrent size plays a major roll in decision making.

@thebigmunch
Copy link
Member

thebigmunch commented Jul 13, 2020

This has come up before. This isn't really going to happen without someone else doing the work to restructure parts of the code.

@satcos
Copy link
Author

satcos commented Jul 13, 2020

I would like to take up the work, If you could share details of your test environment it will help me get started quickly

satcos added a commit to satcos/autodl-irssi that referenced this issue Jul 19, 2020
…g criteria autodl-community#201"

autodl-community#201 (comment)

The fix is designed to bring minimum changes to the flow and as well as to achieve the end result
Two major changes
1. Filter manager performs a soft check on torrent size. When "torrentSizeInBytes" is not defined, treats the condition as satisfied, if defined checks the condition.
2. MatchedRelease when size condition is not met instead of aborting the process triggers the filter check and download process again with additional information of "torrentSizeInBytes"

Short comings of the fix
1. Under certain conditions torrent file is downloaded twice. 2nd download of torrent file certainly leads to an action.
2. Time and computation wasted in rechecking the filter

Possible improvements
1. Avoid downloading torrent file again, if it is available in temp
2. Parse torrentSizeInBytes from IRC announcement wherever possible
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants