Hi all,
I’m a fan and user of both mopidy and beets. I want to combine them in a way so I can support beet queries in playlists.
Imagine the following:
- In playlists, for example m3u playlists using the M3U Playlist extension, and there are entries using the uri
beetsquery:albumartist:muse album:drones track+.
- Then the
beetsquery backend, which has already loaded the beets database, executes the query and generates a list of mopidy Tracks with their uri pointing to the path returned by beets, e.g. file:///data/Music/Muse/Drones/01.flac
This will allow us to take advantage of the powerful beets query language and run queries like beetsquery:genre:garage or beetsquery:year:2010..2015
The way I’m thinking to implement this I won’t be implementing a real backend but a meta-backend, which will run a query and add Tracks to the queue for the streaming backend to play. Since there is no access to core in backend extensions -but only in frontend extensions- I need some pointers on what to overload to achieve my goal.
Ideas and / or other approaches are welcome. I just started to dive into mopidy’s code so I could be missing something.
Thanks!
Some thing like that should be doable, have you checked if one of, or both of the following extensions might solve what you are looking for?
And yes having a backend that only implements library features and returns URLs that some other backend can handle is supported.
I think beets-local is close but as far as I understand it doesn’t allow user to run raw beet queries and directly play the results. Maybe @rawdlite can comment?
Can you give me some hints? Want I actually want is a translate_uri like method which can return a list of uris.
mopidy.core — Core API — Mopidy 4.0.0a1 documentation is what you just described. The backend version of this is lookup(uri) --> list[Tracks].
Hi Giorgos,
I also like mopidy and beets a lot, which is the reason i wrote beets-local to have a feature complete local backend for mopidy.
Now what beets-local does is, it takes search and browse requests from mopidy-core, translates them to a beets query and runs them against beets using its API. Unfortunately syntax and structure from mopidys queries and beets queries differ quite a lot. Not all of beets query abilities can be expressed in a mopidy query. (And vice versa)
That being said, i think the browse function in beets-local could be adapted to accept a native beets query as i am pretty free in the way i build the url schema and the browse tree there.
The result would be a list of Tracks and Albums ( Although i haven’t yet seen a client that uses the returned albums array )
A client that issues this raw beets queries as browse request an adds the result to the mopidy play queue would need to be written.
I started a a headless client https://github.com/rawdlite/mopidy-remote that could be extended to do that.
On the other hand you could just use a beets plugin to build mopidy playlists from beets queries.
HTH