[Feature Request] Prioritize searches containing any of substrings by their defined order

[ShanaryS]

Certain release groups are more likely to be cross seeded than others like NTb. So searching for those first would have cross seeding happen quicker when searching on a new indexer. I've implemented this on my own branch and it dramatically speeds up matches 10x.

Very simple change, only needs to sort results in pipeline.ts findSearchableTorrents():

...

// Prioritize searches that contain any of substrings by their defined order, case-sensitive
if (prioritizeSubstrings.length > 0) {
	filteredTorrents.sort((a: Searchee, b: Searchee) => {
		for (const substring of prioritizeSubstrings) {
			if (a.name.includes(substring) && !b.name.includes(substring)) {
				return -1;
			} else if (!a.name.includes(substring) && b.name.includes(substring)) {
				return 1;
			}
		}
		return 0;
	});
	logger.info({
		label: Label.SEARCH,
		message: `Prioritized searches containing any of [${prioritizeSubstrings}] by defined order`
	});
}

return { samples: filteredTorrents, hashesToExclude };

If accepted, will create the PR.

[zakkarry]

I'm not sure I understand what this accomplishes in practice. Given that initial searches would be what I think you are implying benefit from this, since most cadence level searches shouldn't take that long, on top of RSS or autobrr catching most of the potential cross-seeds, or being limited in # of searches with excluding...it would seem like the benefit of at most a few days, in the worst case, of seeding time on what would in almost every case be older stuff is pretty negligible?

I'd be interested to hear what this provides from someone who uses it (you) if you don't mind.

[ShanaryS]

Yes, it would only be for initial searches / new database. The initial search for me takes about 4 weeks to complete as I use a 5min delay. By prioritizing certain groups, I would get 90% of the cross-seeds in a few days. Lots of places gives points based on seed size so this builds buffer quickly.

I know it's a pretty niche use case but very impactful when needed. It's low hanging fruit with no downsides, easy to maintain too. Just adds an array to the config and use a trivial sorting algorithm in a single place.

I've already gotten my use out of it and can easily maintain this feature in my fork. But I'm sure some else would love this.

[zakkarry]

I've stated this in other issue/PR's but we are generally pretty cautious about adding configuration options, the config can be pretty troublesome for people as it sits. I'm not really leaning one way or the other to the feature at the moment, I'm working on linking enhancements in v6 and a feature request on my other project today amongst a few other things.

I would like to see you drop me a tag in Discord if possible and perhaps we can find some time to talk through some of the implications and integrations you would like to contribute. Just an offer.

[ShanaryS]

Search order now matters with the caching and this isn't that useful. Not worth implementing.