Open binhex opened 2 months ago
Hi @binhex , sorry for the delay in feedback.
I guess my concern with this is it would surface less relevant results to the top, which might not always be wanted/expected, and would also differ from the behaviour of the main API. Bear in mind when specifying something like a TMDB ID it would go on published date, as there's no concept of "relevance" except for free text search. It's a shame the Torznab spec doesn't seem to support specifying any ordering, and given that I'm inclined to go ahead with this PR.
As for your implementation - the default sort order should already be published at, EXCEPT where a search query string was specified. So it should be enough to simply remove the query.OrderByQueryStringRank()
in search.go
.
Hi @mgdigital thanks for the reply no worries about the delay. So I get that relevance might be preferred under certain circumstances, would it be possible to set a command line flag for bitmagnet that defines the sort order?, so something like --sort-order=<relevance|published|...>
that way the user can decide what they want it to be sorted by, with a default of published
or maybe define this option in the classified.yml:-
flags:
sort_order: published
would it be possible to set a command line flag for bitmagnet that defines the sort order?
I've been thinking something like different "profiles" for torznab, that could do things like restrict the search or customize ordering, and make multiple Torznab endpoints available with the different profiles. That might ultimately be preferable to setting such an option globally.
(BTW classifier.yml is for defining the classifier which doesn't really have anything to do with Torznab).
This PR is to switch the Torznab sort order from 'OrderByQueryStringRank' (Relevance) to 'OrderByPublishedAt' (Published) when defining a search criteria.
The Problem
The Solution Switching the sort order to Published date means you get the very latest magnets as they are discovered, which means newer titles tend to be at the beginning of the search list. Due to the list being sorted by Published date it also means there is a much higher chance of at least 1 seed and thus a higher chance of completion.
Hands up here, I have no experience developing in Go, so this implementation maybe done much better in another way, but for now at least it does do what I intended.
EDIT - Due to my lack of knowledge of Go I have switched this to a Draft PR as it no doubt needs further work before being considered for inclusion in main.