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]

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.

[tryffel]

Any update on this?
I have personally used Meilisearch in multiple personal projects and I really love it for typo-tolerant search, for instance.
I could try to create a POC / MR for integrating Meilisearch into Navidrome?

[avh4]

Just to add a concrete example from my actual library, I was searching songs today for "bird" and expected both "Blackbird" and "Bluebird" to appear in the results, but it currently doesn't because of the way search currently works.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Navidrome team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[kaanchan]

[Universal Search Bar] is a different issue, feel free to create a new GH issue for it, although it would help having the SQLite FTS working first.

@deluan What's not working, if anything, for SQLite FTS? Are you considering implementing the above?