Feature: Search limit

[fabricionaweb]

The idea here is to limit the number of queries to be made between each running.

The current feature excludeRecentSearch can already filter off some results, so combined with a limit feature we can have more flexibility.

Example of my usage:

• My library has 440 items
• excludeRecentSearch set to 5 days
• searchLimit set to 100
• searchCadence set to 1 day

Every day the search runs, it picks only the 100 that have not be done before

The user needs to pay attemption of their values or this can keep items out of the search, for example, if the excludeRecentSearch is too short for the limit, it will be start to pick items again...

fixes #432

[mmgoodnow]

i actually removed a limit flag when I added periodic searches, because it felt like it didn't really make sense. However I do see this use case and have wished for something similar.

what if we had a way for cross-seed to automatically balance?

example:

searchCadence 1 day, excludeRecentSearch is 6 months (~180 days), we're running for the first time. 1000 torrents are eligible to run.

therefore, we do one 180th of the torrents, plus some number for good measure.

one problem with this approach would be that as we progress through the 6 months, less and less torrents will be eligible to run. when there are 89 torrents left, a 180th of the eligible torrents would round to 0. so the first time, we'd do like 5, and towards the end we'd be doing less. So it's not fully balanced.

Another approach: we count the total number of torrents, ignoring excludeRecentSearch, then divide that number by 180. Then, we run that number of torrents today (rounding up). this would probably be the most balanced? and it does seem feasible…

[yammes08]

i actually removed a limit flag when I added periodic searches, because it felt like it didn't really make sense. However I do see this use case and have wished for something similar.

what if we had a way for cross-seed to automatically balance?

example:

searchCadence 1 day, excludeRecentSearch is 6 months (~180 days), we're running for the first time. 1000 torrents are eligible to run.

therefore, we do one 180th of the torrents, plus some number for good measure.

one problem with this approach would be that as we progress through the 6 months, less and less torrents will be eligible to run. when there are 89 torrents left, a 180th of the eligible torrents would round to 0. so the first time, we'd do like 5, and towards the end we'd be doing less. So it's not fully balanced.

Another approach: we count the total number of torrents, ignoring excludeRecentSearch, then divide that number by 180. Then, we run that number of torrents today (rounding up). this would probably be the most balanced? and it does seem feasible…

I was chatting to fab about this - that last idea sounds like it would work. So, you could just have an enableSearchLimit flag, true or false, and if true it does the calculation you describe?

[mmgoodnow]

So, you could just have an enableSearchLimit flag, true or false, and if true it does the calculation you describe?

yeah i think so.

[mmgoodnow]

Thank you for the contribution!