normally hass is in charge of downloading and installing required python modules, of which mopidyapi is one.
I am currently running it on a Raspi4 using hassos (production) and one using docker (dev), and I have no problems. So your guess is as good as mine.
Are you able to access pypi.org from your container?
The Spotify resources (as are all Mopidy resources) are limited to whatever the Mopidy API supports.
The structure I get is the following:
Top lists:
Top tracks:
Personal:
Country:
Other countries:
...
Global:
Top albums:
Country:
Other countries:
...
Global:
Top artists:
Personal:
Country:
Other countries:
...
Global:
Your music:
Your tracks:
Your albums:
Playlists:
Featured:
Granted, this could be better, but this is defined by the Mopidy Spotify extension.
If you think you are missing anything, please indicate where above, that’s easier for me.
That said, I just added support for source selection, which lists all your (personal) playlists.
are we talking about files or local media ?
Artwork for local media is tricky, as the location is based on the Mopidy confguration.
If you access your hass instance on the same network as your Mopidy servers, you should get the artwork. Outside of that, it is not available.
This is an improvement I need to research, as it would require hass to ‘proxy’ the artwork in some way, and I have no idea on how to solve this (yet).
you can check which artwork your Mopidy server knows by pointing your browser to:
http://<mopidy server FQDN or IP>:<port, default 6680>/local/
This will either show you a kaleidoscope of album art or present you with a sad white page… In the latter case, you have no artwork.
Another consideration is that your artwork needs to be embedded in your music files as an ID3 tag. If you do not have this, I believe you will have no artwork either.
If I use media browser I can see in Local Media -> Album all the album art in my library, and also the album art for each track if I open a specific album, but when I play a track in the media player card there is no album picture.
If I use media browser in Files, when I choose a directory (album) I have no picture for the related tracks.
Based on your suggestion, if I open http://<mopidy server FQDN or IP>:<port, default 6680>/local/
I see a page with all the album covers.
Ok, I do not know the details, but I have a mopidy setup on my server.
In that mopidy, I can see my playlists and artist from spotify. I would expect those under “Your music” then as well.
Hi, and thank you for making my wishes come true so fast
The on/off switch seems to work fine and as expected, and the source_list gets duly filled with the playlists as defined within mopidy.itself. One ‘however’ : selecting an item from this list does nothing, contrary to the old mpd-integration where it starts playing the selected playlist - as expected …
Furthermore, I have to concur with @elle2 on the subject of the local media artwork problem. Me too, I can see all the artwork on the http://:<port, default 6680>/local/ address, but it fails to show in the player. Furthermore, my artwork is all contained in individual jpg-files, never embedded in the music files themselves - so it seems the latter is rather irrelevant.
The fact that the artwork also shows up perfectly fine in the Iris frontend leads me to thinking that it must be retrievable using the mopidy API - which when true would presumably also alleviate the need to worry about location of the media, mopidy’s configuration, and for any proxy, no ?
Personal playlists (in spotify) are not part of the tree offered through the browse method of the mopidy API.
What you see in the media browser is what I discover through that browse method. I haven’t manually created this.
The playlists are, however, published as a “list”, together with your personal m3u lists in local data, which I then use as source_list
I could try to figure out a way to add them manually to spotify/your music. Do you think that would be an added value?
@pav
The source list selection works on my end. I wonder what is going on.
I’ll see if I can build in some debugs to get to the bottom of this… Are you sure you have installed the latest version, and restarted your HA instance?
@elle2, @pav
Do you know how to use your browser’s “developer tools” to list network activity?
In firefox this is ctrl+shift+e, and will show all resources loaded by your webpage.
You’ll need to reload your page after that.
And then go to the “directory” with the resources which do not show thumbnails.
This screenshot shows the thumbnails, and the list of resources (in the bottom) loaded.
the “status”, “domain” and “file” columns are what we’re looking for.
“status” should be 200, and the domain and file part should tell you the URL used to get the image
When clicking one of those lines, you will get details on that request, as well as the exaxt url used to fetch the image. Check if that works when pasted into your browser’s address field.
Regarding the source list: I installed a new version about one hour before my previous reply. And of course restarted HA after that (otherwise it would have been hard to ‘see’ the enhancements, let alone test them ). When the test failed I even reinstalled the old mpd-player to verify the difference between the two - which there definitely was. Could it be it doesn’t work for me because my mopidy playlists (and thus my source list) are all about local media - no spotify involved/integrated in my case ?
My problem with album art is related to media_player card when I’m playing an audio file.
I’ve used the web developer tools (in Chrome) and when I play a track there is no resources linked to mopidy server but only to HA server.
However I 've done two tests:
with a Spotify track I see the correct album art. In this case the Chrome tool show me that there is an image in HA server. The url of this image is the same of the attribute entity_picture of media_player entity entity_picture: /api/media_player_proxy/media_player.testmopidy?token=bc8bf3c5a26bd0e1ea7ddee2a93c49b207931db69944140089dd8a86983a80aa&cache=df8659bba6b79b7b
with a local track I don’t see any album art. Indeed there is always an entity_picture attribute in media_palyer entity but the associated url isn’t available
I hope these info can help you to investigate the problem.
PS. When I’m browsing local media, in the popup window of media_player card, there are the album art and the Chrome console show me that these images are on mopidy server
Fully agree with @elle2. When playing a local track, the entity_picture attribute has content, but the associated url points to nowhere (chrome shows the ‘500’ result).
I should also point out that the old mpd-player (which I have still running alongside) shows exactly the same behavior.
Edit: I tested with a tune-in internet radio source, started with mopidy. The good news is that the associated station artwork gets shown, whereas the old mpd-player never did.
@pav
I believe I have fixed the m3u playlist issue in my latest commit… It took me a while before I understood how the m3u extension works (API wise), but I was able to run it on my end. As long as your playlist is created through Mopidy, it should work.
@elle2, @pav
I believe I understand your issue with thumbnail now… it’s only when you’re playing that the image doesn’t show in the media card. thumbnails through the media browser work.
And I can reproduce it in both my docker and HassOs setup.
I have no idea how to fix it, but I will look into this.
@elle2@pav
I believe I have fixed the thumbnail showing up in the player during playback.
I also introduced a bug in fixing the playback of m3u playlists, which should be fixed now.
@bushvin
Great, now I can see the thumbnail while playing for the local track as well.
And source management (spotify and local playlists) is fine too.
Just a little note: if I play a local m3u playlist there are no album art in the media_player card (instead it’s okay if I play the single track). With spotify playlist, everything is fine.
Thank you again.
EDIT: I’ve solved the little issue for album art in m3u playlist. The mp3 file had to have embedded picture and also the m3u file needs to refer the file as local:track. This component is really fine. Thanks to @bushvin, good job.
@bushvin
Major improvements made again. Very happy with the source list/playlist activation working perfectly.
And no less with the artwork showing whilst playing. I even want to report that on my side it also shows when playing a local playlist, contrary to what @elle2 seems to experience. Maybe due to a difference in embedded/non-embedded artwork in the tracks (remember: I only have non-embedded) ?
Coming back to your ‘it’s only when you’re playing that the image doesn’t show in the media card. thumbnails through the media browser work’ remark, I hate to say that I don’t see any thumnails using the media browser. Never have, also not with the latest version.
Edit: when using the media browser to browse the tune-in radio stations, I DO see the station thumbnails - contrary to when I browse my ‘local’ stuff
Anyway, perfection is in sight thanks to your much appreciated efforts. Thanks a lot !
Hi,
Thanks for adding the support of sources, I can get rid of the mpd media controller now and select my spotify playlists.
Your integration works great so far, that’s pretty cool. Hope it can get officially supported in the future.
Please excuse my ignorance on such things. I was looking for a way to multi-room stream sound-cloud to air-play devices like the homepod.
I was looking for Mopidy for sound-cloud, so this looks very good.
Can I use this add-on to stream to multi room air-play devices? Would I need to also install forked-daapd for the air-play side? Would the two add-ons work together?