Skip to main content

## Module search_rank

Source
Expand description

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.