OK, great -- I'm glad we can use Typesense, since this is going to be easier than messing about with the other search approach. Phew.
As for integrating Troi into Funkwhale, I've learned a few things in the past few weeks and now think it would be better to not add content resolution to Troi (that is not its intended job, really). A better way forward is to have the FW content resolver read JSPF playlists and then resolve them to local files. This way troi does not need to be modified and it becomes location agnostic, meaning that we can embed it into FW or have it hosted someplace else. JSPF is well suited for this purpose and makes everything, more interconnected and modular.
Which is why I was started the listenbrainz-content-resolver project -- it has become clear that more people are interested in this project, so it follows the JSPF -> resolved JSPF/m3u format path.
As for creating a content resolver in FW, I can totally see how the internal DB might make it better to have the resolver in FW, no problem. But, remember that the resolver has two distinct parts that are both critical:
- Search for tracks (solved)
- De-tune metadata. This component takes a potentially dirty track/artist names and converts it to something that is clean. Example: "Inhale - Radio edit 1997" -> "Inhale"
Playlist metadata and funkwhale metadata may either/both contain this cruft and that complicates content resolution. Of the two components, the first one is pretty simple. When its done, its done. The latter is going to evolve over time as people make the detuning process better. If you don't use the LB library for this, you will have to continually improve/update this code as your users find tracks that are not matched.
What I can do is re-work the lb content resolver to expose the de-tuning engine with a minimal set of requirements -- quite possibly 1 or 2 python libraries (unidecode is one). This way you can include the library without adding a lot more stuff to install.
So, the lookup process then goes like this:
- Build the typesense index duplicate metadata records, one for the original metadata and one for a detuned version (if it can be detuned). Insert both (all?) records into the index. This ensures that the detuning happens on the FW side and on the inbound metadata side.
- Lookup track with metadata as given. Success? Done.
- No matches? Examine the given metadata and run query artist and/or recording through the detuner. If the detuning was successful, redo the lookup.
- Still no luck? Bummer.
How does all this sound?
