-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Searching for exact matches #11
Comments
Agree! Should do this differently for the upcoming Mopidy-Spotify 2.0. |
Do you think there is any merit in doing this in pyspotify 2.0? At least the exact searches bit. I vaguely remember the mention of an additional higher-level wrapper that did some extra useful stuff (I think this was based around the bug where starred playlists have no name), |
It's worth considering at least. The immediate issue I can think of is how to make an "exact match" overlay over the existing search work nicely with pagination. If you search for "foo" and ask for 20 results, then you're told that "we found 73 results, here's the first 20" and then there's only 18 in the result, since two wasn't exact matches. |
mopidy/mopidy#272 seems relevant here. We should consider using artist/albumbrowse instead of or in addition to search for find_exact. |
To move the entire discussion over here, I'm quoting @trygveaa from mopidy/mopidy#272:
|
From the discussion in mopidy/mopidy#727 it sounds like making exact searches exact would help on data quality in the ncmpcpp library view as well. |
This needs updating, especially given Spotify's latest fiddling to how search works. What does the web API now do and can we do better? |
When using MPD's
find
command the results are supposed to be an exact match of the query but due to limitations in Spotify's searching you actually get partial matches more akin to SQL's LIKE operator.e.g. Searching for "Opposite of December" gives you results from two albums:
This is pretty annoying when you browse an artist's album in MPD clients and get wrong and duplicate tracks entries.
I know of no way to force exact matching in Spotify queries so maybe we could further filter the results returned to us in
find_exact()
? Similarly, we could also filter by the fields that Spotify queries don't support i.e.track_no
. The motivation for this being that much larger amounts of data are returned to the client than are necessary and it just slows things down. This also combines with the first problem and you can get the full track info for loads of unwanted tracks!The text was updated successfully, but these errors were encountered: