# Local Libraries and the add\_supports\_tags\_and\_duration flag

**URL:** <https://discourse.mopidy.com/t/local-libraries-and-the-add-supports-tags-and-duration-flag/3073>\
**Category:** Misc\
**Created:** [February 3, 2019, 1:40pm UTC](https://discourse.mopidy.com/t/local-libraries-and-the-add-supports-tags-and-duration-flag/3073 "2019-02-03T13:40:28Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![SMobius](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.mopidy.com/smobius/32/1094_2.png) [@SMobius](https://discourse.mopidy.com/u/SMobius)\
**Post date:** [February 3, 2019, 1:40pm UTC](https://discourse.mopidy.com/t/local-libraries-and-the-add-supports-tags-and-duration-flag/3073/1 "2019-02-03T13:40:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![kingosticks](https://avatars.discourse-cdn.com/v4/letter/k/858c86/32.png) [@kingosticks](https://discourse.mopidy.com/u/kingosticks)\
**Post date:** [February 14, 2019, 12:31am UTC](https://discourse.mopidy.com/t/local-libraries-and-the-add-supports-tags-and-duration-flag/3073/2 "2019-02-14T00:31:53Z")

</div>

Mopidy-Local-Images supports that flag.

> <https://github.com/mopidy/mopidy-local-images/blob/ff31e04789a4ed77a2d8dfe2f36d85e7fab1656c/mopidy_local_images/library.py#L56>

It extracts any cover art defined in the full tags dict, which it then uses to set the `Track`'s `Album` `image` 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](https://github.com/mopidy/mopidy/pull/559). There’s also [this very old proposal](https://github.com/mopidy/mopidy/pull/507/files) 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.