It’s not a problem per-se, I meant we don’t have anything in our current Core API that supports this. Since there’s not much demand it’s never been on our roadmap and so we’d need someone to drive the idea and ideally the implementation also.
Having Mopidy Core pass Backend-specific requests from clients to Backends is something we have so far managed to avoid but I don’t think there’s any technical reason blocking that. One potential issue is that different Backends could have very different ideas of how to answer a given query if there are no conventions defined by our API. However, we could solve that with a
uris argument, similar to what LibraryController.search accepts. Alternatively we could define some conventions but then you’d have to ask why aren’t they just new fields added to the models?
I’ll also point out that the Local backend does not currently lookup/scan media outside of doing
mopidy local scan i.e. not while answering Core API requests during normal operation. In fact, all our Backends currently have the luxury of relying on there being a well-defined and restricted set of data they need to store/cache/handle. It would probably be OK in the case of Mopidy-Local to support scanning tracks on demand in order to retrieve arbitrary tags as:
- We already handle all data types that GST might return to us
- It should be relatively quick to do
But it may have more of an impact for other Backends that rely on caching to be performant enough for use.
I can’t find any existing issues for this (other than https://github.com/mopidy/mopidy/issues/1644 which is slightly different because it wants to also store arbitrary tags) so if you are interested in fleshing this out a bit more do you want to create a new feature request?