Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
list <artist / album etc.> iterates over all local tracks #913
If you call mopidy with a 'list albums' or 'list artists' command, how it is handled is:
How it should work:
This causes a bug in the sqlite backend, because that backend sanity checks the general 'search' command and limits it to 100 results, and also means that listing artists / albums etc. is very slow if you have even a vaguely large local database. I imagine it also massively slows down the various search things in spotify/google music etc, because presumably if you search for artist it has to return all the tracks by that artist first?
This is not obvious in musicbox, because it doesn't use the list command at all, but breaks most clients (MPDroid, NCMPCPP both support browsing by artist or album).
Description of the sqlite backend bug caused by this here:
Example of the underlying code that needs fixing:
I've lost track of if I ever opened a bug for the following idea, or just mentioned when talking with jodal. But I suspect we want / need some API in the backends that allows for a more efficient look-up for cases like this. As currently there is no way for backends to provide these listings in an efficient manner.
One possible neat and tidy way would be for find_exact in library to take a further argument, that said what return type you were looking for.
If expectedReturnType=TRACK or expectedReturnType=ALBUM or whatever then in the back end, you return models.SearchResult with that type.
Now, obviously this would require the update of backends to support this in the long term. However, you could use inspect on each backend to find out whether it supported expectedReturnType, and drop back to the current behaviour otherwise (or implement it via catching the 'unexpected argument exception', which would work fine given the function call timing itself is hardly a bottleneck in comparison to all the db/filesystem lookups.
It'd be a pretty minor change - would need:
Looking in the code comments, I can see that there is a further idea for a tidy up of search and find_exact, so that all code calls 'search', with an argument like 'exact=true' to do what find_exact does.
So this would be an optional argument to search similar to this, and could in fact be implemented at the same time, with the backend base class handling non-updated backends that still use find_exact and don't support return type choice.
Is there any reason I shouldn't implement these optional args to search (plus tests) and do a pull request? ie. might someone else be working on them?
referenced this issue
Dec 21, 2014
Sounds like a reasonable direction to go in. While on the topic I should also mention https://docs.google.com/a/adamcik.no/document/d/1TphZ2dofTvnxk54UxVOQkhIhzVUwChmfWwMHA-vJfaU/edit as one of the future plans and https://docs.google.com/a/adamcik.no/document/d/15hEZkB0_W33vUD-pKsf-gk3BICDgxsa1FC0H_lMXFUU/edit#heading=h.ovemgfx92e2j
Though starting with smaller refactorings like you suggest is likely best.
referenced this issue
Mar 1, 2015
We just merged #1022 which adds a new API for getting these distinct values. Internally the JSON backend still does the same stupid thing, but at least now mopidy-local-sqlite can do a sane distinct query.
In other words I'm considering this solved, as I've opened #1019 to try and hunt down other places relying to "blank" searches to get all the tracks and do stuff with them.