Media Player platform for Mopidy

Hi @AdmiralStipe

Can you tell me a bit more?
Do you play this stream through TuneIn? Or another Mopidy Extension? Or did you specify a stream URL?
Would it be possible to post the uri playing?

You should be able to get that when viewing your media player through the developers tools:

  1. click on Developer Tools in the left menu
  2. click on the States tab
  3. select your media player (media_player.<something>) in the entity field
  4. look for media_content_id in the resulting data in the State attributes (YAML, optional) text field.

I will check if there’s something I missed in the platform.

thanks in advance

If I play the stream through TuneIn, it show the data correctly (but I don’t want to always play a TuneIn stream), the problem is, when i play a custom stream specified by URL (more precisely, m3u playlist, within which the stream is defined). In my case it’s f.e. “http://stream.rockradio.si:9034/;stream/1” or “https://mp3.rtvslo.si/val202”.

If I try a different media player (for example HA native MPD), it shows the data correctly, the difference shows in State attributes as follows:

your platform:
media_content_id: ‘http://stream.rockradio.si:9034/;stream/1
media_content_type: music
media_position: 148
media_position_updated_at: ‘2021-02-12T09:00:35.526066+00:00’
media_title: ROCK RADIO SI
media_playlist: Rock Radio

native MPD:
media_content_id: ‘http://stream.rockradio.si:9034/;stream/1
media_content_type: music
media_position: 271
media_position_updated_at: ‘2021-02-12T09:02:38.233136+00:00’
media_title: ‘ROCK RADIO SI: ROLLING STONES - SAINT OF ME’

So I assume different platforms read stream attributes differently, or?

The API is indeed different, and I may have missed some bits and ends, so I’m really grateful for this kind of feedback.

I’ll see what I can come up with, but no promises for today.

Thanks for the URL.

1 Like

Just a remark here… if it would be possible to exclude the stream name from “media_title” and put it in a different attribute (so to split it), that would be just awesome. So, f.e., the attributes would show:

media_title: ‘ROLLING STONES - SAINT OF ME’
media_source: ‘ROCK RADIO SI’

instead of
media_title: ‘ROCK RADIO SI: ROLLING STONES - SAINT OF ME’

That’s a good suggestion, however, I’m not sure how to handle media_source

Oh, it doesn’t have to be exactly “media_source”, it could be anything you find easy to implement… if no other solution is available, just stripping the stream name out of actual media title would be enough, so that just the actual artist and title remain in “media_title”.

Can you update and have a look?
It was (fortunately) more easy than expected.
Instead of mapping the name of the stream to media_source, I mapped it to media_artist, resulting in this:
media_player

Perfect, I’m more than happy :).
Thx a lot for your promptness and good work.

Hopefully this didn’t spoil the experience for someone else, who was happy with the previous mapping.

1 Like

IMO this is an added value, not a regression…

Just a heads up for the upcoming release tomorrow, there’s a breaking change for custom components, see the PR here

Would be great if you adopt your repo accordingly.

Thanks again for your hard work on this, still love it :slight_smile:

2 Likes

Hey @Burningstone,
Thank you for this heads up.
I updated the repo as per the documentation.

1 Like

Warning gone, works perfectly fine, thanks a lot!

Though more than happy and thankful for this very useful mopidy player, I cannot help returning to the Iris frontend most of the time. Simply because of the missing local media artwork when using the embedded media browser. I know and understand that

due to the nature of the way Mopidy provides thumbnails of the media, proxying them through Home Assistant is very resource intensive, causing delays. Therefore, I have decided to not proxy the art when using the Media Library for the time being

but I would like to nevertheless humbly ask you to have a second look at this, based on the following remarks :

  • the Iris frontend seems to be able to serve up the album artwork quite fast - so maybe some inspiration can be gotten from looking at its corresponding source code ?

  • if this proves to be a bit of a dead end, then maybe you could provide us with a configuration option to switch the artwork retrieval and display on or off ? Such that those of us either running on somewhat performant hardware, and/or willing to take the maybe unavoidable performance hit, could get and enjoy their visual candy :smiley: ?

Thanks for considering this …

Hi @pav,

If you are in the same network (ie, you’re not on mobile data or so) as your mopidy server, you should be able to see your media artwork through your home assistant web interface or app. Are you saying you cannot? If not could you provide me with some information:

  • mopidy server version
  • is mopidy running on the same host as your home assistant?
  • is your mopidy server running in the same network as your home assistant (if previous Q was no)?
  • what is your local media on your mopidy server? is it a local folder? is it a samba (windows) or nfs share mounted? Something totally different?
  • when browsing to http://<mopidy server ip>:6680/local/ you should be able to see all your artwork. is this the case?
  • is your app on android, apple, or something else?

Adding the option through the configuration is something I had been thinking about myself, so I will definitely be looking into it.
The iris code could yield some interesting points, yes, but I believe the limit is with the way the media library is implemented. When you create a responsive app, you typically only load images which are visible. I’ve noticed home assistant media library loads all, i/o only the ones displayed. Mopidy has an API which will fetch the media URL, but each call takes a lot of time. So you would (like I do now) group your image URL retrievals in batches of 100 or so) that way the time overhead to initiate and negotiate the connection is minimized. Anyway, I will have a look.

Right now I am working on integrating mopidy with the flows, so mopidy servers can be detected/added through the integration page, so my focus is there for the moment.

1 Like

Hi @bushvin,

Thanks for your quick reply. I’ll first provide you with the requested info:

  • mopidy server version: latest, i.e. v3.1.1
  • is mopidy running on the same host as your home assistant? yes
  • is your mopidy server running in the same network as your home assistant (if previous Q was no)?
  • what is your local media on your mopidy server? is it a local folder? is it a samba (windows) or nfs share mounted? Something totally different? Samba share on NAS (but mopidy replicates the artwork locally anyway, no ?)
  • when browsing to http://:6680/local/ you should be able to see all your artwork. is this the case? yes (and served up quite fast …)
  • is your app on android, apple, or something else? using it mostly through the browser on my laptop (but problem is the same through the app on my android mobile)

Just to be sure: you might remember that I keep my artwork non-embedded - although that should not make a difference since you’re proxying through mopidy ?

What is becoming rather unclear to me is that you seem to be implying that I should be able to see my artwork, which seems to contradict the statement on your github which I quoted previously (the one saying ‘Therefore, I have decided to not proxy the art when using the Media Library for the time being’) ?

Anyway, this is what the mopidy server shows:


and this what I get from the player :

Notice the occasional appearance of an LP-icon on some albums - no idea why it appears on some, and not on others …

Please advise if you need any additional info.
Best regards !

Yes, the album art should be displayed when connecting from your local network.

HASS will provide a url to your local mopidy server normally…

When pressing 12 in Firefox you get the network console, which shows you all resources loaded and results…
As you can see in the above screenshot, there’s a lot of resources loaded from my mopidy server (figrindan). Each line is a jpeg, which should be accessible when you copy/paste it into your browser.
For instance:
http://figrindan:6680/local/9aa31a6f43216e6301e217e9e495c0a2-301x300.jpeg?t=x points to my local mopidy server, and when accessed, should bring up this album cover

If yours is not showing, there may be something else going on, and I would like to get to the bottom…

Bingo ! You nailed it …
When checking the above (using Chrome, but shouldn’t matter) I had tons of errors about the jpg-fetching. Looking closer, I noticed that mine were being fetched at the localhost address (which is what I have in the host setting of your player’s config). Sooo … changed it to the actual mopidy server’s address, rebooted and … bingo ! Artwork showing up nicely and with more than acceptable speed.

A bit surprised that this mishap only affected the artwork display, but not the actual playing of the albums, but hey, I’m sure there’s a logical explanation for that too :grin:

Anyway, very happy camper now - and so sorry for bothering you with this.
Thanks for your top-notch support !

1 Like

@pav you are very welcome!

hass is controlling mopidy over localhost, as they are on the same host, but your computer is not…

the URLs you receive refer to localhost, which your system thinks Hey, it’s me!

This is actually very useful information, and I will add it to the documentation, so thank you for helping debug!

ANNOUNCEMENT

This time for real :wink:
RIght in time for the week-end!

I was finally able to code the configuration flow as per the Home Assistant documentation.

Pull your latest and try it out!

Here’s the github project

After installing, please restart Home Assistant and refresh your Web browser.

1 Like

Sorry to say, but … no dice. Integration Mopidy cannot be added due to simply not being found (and yes, I restarted after installing the new component).