Advanced Search Options

[8ullyMaguire]

An advanced search feature would greatly improve the usability of bitmagnet by allowing users to craft more precise and complex queries. Here are some suggested search options to implement:

• Scope Search: Ability to limit the search scope to title only, content only, or both title and content.
• Field-Specific Search: Ability to search within specific fields like title, description, tags, source, resolution, etc.
• Exact Phrase Search: Search for an exact sequence of words by enclosing the phrase in double quotes, e.g., "Keyword1 keyword2". For instance, a search for "kw1 kw2" kw3 kw4 would return results containing kw1 and kw2 together (in that order), and kw3 and kw4 appearing anywhere in the result.
• Boolean Operators: Support for combining keywords with boolean operators (AND &, OR |, NOT -) for more complex queries.
• Wildcard Matching: Using wildcards like * or ? to match patterns (e.g., s01ep* to match episode numbers).
• Regular Expression Search: Support for using regular expressions in search queries for advanced pattern matching.
• Saved Searches: Allow users to save complex search queries for future use.
• Numeric Range Filters: Filter results based on numeric ranges for fields like date, size, number of files, seeds, etc.

Implementing these features would allow users to craft very precise searches to quickly find their desired content. It would make Bitmagnet's search capabilities highly competitive with other torrent sites. I think they often don't offer these features on websites because they are resource-intensive, but they are a good fit for a self-hosted program. Please consider adding advanced search options!

There are other ideas for a visual style advanced search instead of syntax based on this issue

Related

• Scope Search to Title, Content or Both
• Numeric Range Filters
• Exact Phrase Search
• Boolean Operators
• Hash Search
• Saved Searches
• Regular Expression Search
• Wildcard Matching
• Field-Specific Search

[mgdigital]

Hi, agreed on a lot of this but I think there are several separate features here so this might need splitting across a few issues:

The first, and possibly simplest to fix is the search query string.

The current search implementation has only one catch-all way of interpreting the string, which tries as user-friendly as possible, combining several ways of normalizing and checking the input string against the tsv and search_string fields. This may be suboptimal as a query (and should probably be reviewed) but works pretty well for simple search queries: https://github.com/bitmagnet-io/bitmagnet/blob/main/internal/database/query/criteria.go#L167

What we probably want is a checkbox in the UI along with an API param something like queryStringType that could be either simple (as above) or complex, which would do a websearch_to_tsquery against the tsv field without the token normalization and other stuff. That would allow for wildcards, operators etc. Docs for this here: https://www.postgresql.org/docs/current/textsearch-controls.html#TEXTSEARCH-PARSING-QUERIES

The current highest priority issue is the crawler rewrite but this could probably come soon after.

For the other things you mentioned:

Scope search to title only, content only, or both title and content
Field search - Allow searching specific fields like title, description, tags, source, resolution, etc
Regular expressions - Support regex in queries for power users

We need to balance search capability and resource demands - many people may be running this on modest hardware. We currently have a single search_string field that is stored as a TSV in the database and is a concatenation of most of the fields you'd expect in a text search. We also already have facets and filters for things like tags, resolution. Anything beyond this that would require further indexes to be maintained would need justification as to the use case and added benefit...

Save searches - Let users save complex searches for repeated use
Numeric range filters - filter by date, size, files, seeds, etc.
More than 10 files and less than 1000
Size greater than 10 GB and less than 500 GB
Age less than 6 months
More than 3 seeders

These are all valid features but they'll have to be implemented separately, and some would need discussion, so these would be easier to digest/discuss as separate feature requests.