Navidrome: Implement proper Full Text Search

[brianpierson2020]

Maybe we could introduce a feature that asks "Did you mean... ?" showing the closes matches when there are not matches.

This could be incredible helpful on big libraries when making a typo of when the spelling is just a little different like US or UK English.

Another option (less fancy) might be to include some kind of fuzzy search and/or allowing wildcards.

[deluan]

This requires a proper Full Text Search implementation. Subsonic and its Java clones use the awesome Lucene library (that would support a "did you mean" feature easily), but it would be too heavyweight to use it in Navidrome.

There are options in the Go-land (like Bleve), but they are usually slow to update the index (making the scan too slow) and/or takes a lot of memory, going against one of the goals of Navidrome: to be as lightweigth as possible.

Having said that, I plan to move the search to SQLite's Full Text Search implementation. This would help with typos and more relevant search results, and maybe would allow a "Did you mean" like functionality in the future.

[SpencerDub]

Having said that, I plan to move the search to SQLite's Full Text Search implementation.

@deluan, would that allow for a single universal search bar instead of the current view-specific search (search albums/tracks/artists)?

[deluan]

A single search bar is more of a UX concern than a technical implementation. The current "search" fields are actually filters for the current view.

It is a different issue, feel free to create a new GH issue for it, although it would help having the SQLite FTS working first.

[orlea]

Other than English, for example Japanese are not separated by spaces per word, so they can't use the full-text search for English .

It would be hard to make the full-text search work for various languages.
So it would be very nice if partial match search could be used instead of full text search, depending on the setting.

For example, if you want to search for the word "音楽"
LIKE '%音楽%' in SQL

I expect it to be very slow, but I still think better results than putting Chinese, Japanese, Korean, etc. into a full-text search for English.

[orlea]

https://github.com/deluan/navidrome/compare/v0.31.0...orlea:feature/simple-search

This modified code actually works well enough in my 8000 song music library. However, it's probably bad for English etc.
I think it would be better to make it configurable with environment variables like ND_SEARCHSEPARATOR(" " or "").
I don't know how to read and use settings from environment variables etc., as I'm a programming novice.

[deluan]

Hi @orlea , thanks for looking into this! I did some quick research for FTS in Asian languages and doesn't seem to exist a simple solution to the problem. I'll make the separator configurable as you suggested.

Whenever I implement a real (western) FTS in Navidrome, I'll keep the current implementation as a configurable option.

[orlea]

@deluan
Thank you. I tried the develop tag docker image. (Version 0.31.0-SNAPSHOT (76e5227))
The search that was a problem for my use case has been solved!

I tried emby, airsonic, and navidrome in parallel, but I liked navidrome the best.
It's the lightest and fastest.