I’m wondering if Mopidy is a good start for the kind of music player I’ve been looking for for a while. The short version is that I’d want to expose more (in the case id3v2) tags than seem to be present in the Mopidy “track” structure.
I see that the Local Library API supports an “add_supports_tags_and_duration” flag and allows “all” these tags to be passed to the library, however I don’t see any way to get those tags back out of the library, (and I don’t see any library backend that supports this flag) is that correct? I was hoping that maybe an extra “tags” dictionary might make it out to the http interface as an optional property.
I’m comfortable writing code to support these things at the library end and the client end, just need to understand if there are infrastructure blockers.
It extracts any cover art defined in the full tags dict, which it then uses to set the Track's Albumimage field (and then delegate the rest to the normal Local backend). Alternatively it could have stored that data itself and used it to answer get_images requests but that’s only because Album images are a supported concept in Mopidy . You are right, there isn’t a way to expose anything other than what our models currently support. I guess you could jam your other stuff in the comment field that but that’s pretty ugly.
If you want to add some specific fields, create a GitHub issue and we could look at doing that as we have done so before. There’s also this very old proposal for a more generic MetadataProvider that never went anywhere (I don’t know why). I don’t believe you can just add a dict field to our (immutable) models due to the way they are implemented.