Module search_rank 

Relevance ranking for search results.

Both search paths (the SQLite FTS cache and the Jellyfin server) return items in an order that ignores where in the name the query matched: a server substring hit like “Sparks of Love” can outrank “Parks and Recreation” for the query “parks”. Neither backend is going to change, so the app imposes its own ordering on the union.

Ranking is domain logic, not presentation: it encodes what a “better match” means and which media kinds outrank which. The frontend only renders the order it is given.

Two rules, in priority order:

1. Match position — a prefix match beats a word-start match, which beats a mid-word substring match. This is what makes “parks” find “Parks and Recreation” before “Sparks of Love”.
2. Kind — containers before their contents at equal match quality, so a series outranks its own episodes.

Ties fall back to the input order, so a backend’s own relevance signal (FTS rank) still breaks ties it was never overruled on.

Enums

MatchQuality

How well a query matched an item’s name — better matches sort first.

Functions

kind_rank 🔒

Rank of a media kind when match quality ties — lower sorts first.

match_quality

Classify how query matches name, case-insensitively.

rank_search_results

Sort search results by relevance to query, in place.