Include Albums and Artists in Search Results about mopidy-local

[chrisgee]

any plans to add this? I have a (stupid) patch that yields Albums and Artists of the found tracks. Of course this may be incomplete as not all matching tracks for the search are returned. Anyway here is my patch:

diff --git a/mopidy_local_sqlite/library.py b/mopidy_local_sqlite/library.py
index 594068b..312961b 100644
--- a/mopidy_local_sqlite/library.py
+++ b/mopidy_local_sqlite/library.py
@@ -79,8 +79,18 @@ class SQLiteLibrary(local.Library):
         filters = [f for uri in uris or [] for f in self._filters(uri) if f]
         with self._connect() as c:
             tracks = schema.search_tracks(c, q, limit, offset, exact, filters)
+        #extract album and artist data from the search result
+        #fixme: this only yields albums and artists that are referenced by the 
+        #tracks result, which may be incomplete in case there is more than limit
+        #matching entries. To get the right behaviour, FTS should be implemented
+        #for artists and albums as well... (in the sql schema)
+        albums = set()
+        artists = set()
+        for t in tracks:
+            albums.add(t.album)
+            artists.add(t.artist)
         uri = uritools.uricompose('local', path='search', query=q)
-        return SearchResult(uri=uri, tracks=tracks)
+        return SearchResult(uri=uri, tracks=tracks, artists = artists, albums = albums)
 
     def get_distinct(self, field, query=None):
         q = []

I am sure, a proper solution would be to implement FTS for album and artist tables. But as I am not fluent in SQL, that's beyond my capabilities

[tkem]

Thanks for sharing, but this wasn't exactly what I had in mind, though I see that it will improve things somewhat for some use cases.

I'd refrain from merging this though, because of the number of false positives it generates - for example, if the search string is found only in one track's title, I wouldn't expect the track's album to be part of the result.

[tkem]

@chrisgee: The really tricky part is not just implementing this in SQL/FTS, but doing so efficiently, so it will run with medium-sized libraries (say 10,000 - 100,000 tracks) on a Pi0 in less than a second or so ;-)