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:
click on Developer Tools in the left menu
click on the States tab
select your media player (media_player.<something>) in the entity field
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.
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?
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’
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:
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 ?
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.
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’) ?
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
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
Anyway, very happy camper now - and so sorry for bothering you with this.
Thanks for your top-notch support !
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).