Closed dflvunoooooo closed 9 months ago
I got it to work ish by removing and re-adding the integration. I've also created custom scripts to call "play", "stop" etc - these work OK - but yes something has broken with the main media player.
Sadly, this does not work for me. Re-adding yields in a unavailable entity, which turns into unknown after a few seconds.
The no image_url
is actually just a warning when playing streams, which typically have no image, these can be disregarded.
If the mopidy integration has issues connecting to the mopidy servers there should be errors. Seeing you het warnings, you didn't disable this.
Is your mopidy server on your home assistant instance?
What is your mopidy server version?
Using a browser, can you browse to the url of your mopidy player? Eg http://<ip address>:6680/
The mopidy integration in HA 2024.1.0 does not have entity picture, and in Device info has "Mopidy server None by Mopidy". It can play media and tts notification. In Log details (ERROR), it's shown:
This error originated from a custom integration.
Logger: custom_components.mopidy.media_player
Source: custom_components/mopidy/media_player.py:501
Integration: Mopidy (documentation,issues)
First occurred: 5:44:27 PM (4 occurrences)
Last logged: 7:45:58 PM
media_player.mopidy_http_server_on_debian_6680 is unavailable
The
no image_url
is actually just a warning when playing streams, which typically have no image, these can be disregarded.If the mopidy integration has issues connecting to the mopidy servers there should be errors. Seeing you het warnings, you didn't disable this.
Is your mopidy server on your home assistant instance? What is your mopidy server version? Using a browser, can you browse to the url of your mopidy player? Eg
http://<ip address>:6680/
Yes, thank you. I read in the issue concerning the no image_url
about it.
Yeah, I would expect errors, but there are none. I don't know what you mean by the second sentence, sorry.
No, it is a separate host running mopidy. I am running version 3.4.1-3. I can access mopidy in my browser. The funny thing is, that mopidy is accepting calls from HA, I can use it in automations as usual, but not as a trigger, since it is always unknown.
Could you elaborate on the trigger part? Can you post your automation?
Second sentence: het should be get.
I meant that if you're getting warnings you didn't disable logging.
Could you elaborate on the trigger part? Can you post your automation?
Of cause. But it is not related. I play a radio stream 24h on one mopidy instance. But for some reason, it fails to output audio after a few days. So I have, since I do my automation in node red, a node which outputs the state every time mopidy changes, if the track time, title and so on changes. If this doesn't happen within 30 seconds the automation delets the playlist, starts the stream once again and sends me an notification.
Second sentence: het should be get.
I meant that if you're getting warnings you didn't disable logging.
I did not disable logging. I wasn't aware this is possible.
We seem to have gone off on a tangent.
What I'm seeing as of my update to 2024.1.0 is:
Ultimatly "pause" didn't change the "playing" state accoring to Home Assistant -- but the music did pause.
I can still start/stop/pause my "PiBMopidy" using a mobile app or using scripts / automations fine but the Media Player card does not change or update. I cannot restart play using a "pause" button. Choosing new a new track using the Meida Control card does work (it starts playing the new track) but the track information does not update.
My Mopidy instance is sperate to the Home Assistant device. It is running "Mopidy 3.4.2" and seems to work normally aside from the recent quirk when reduced functionally when using Home Assistant Meida Player cards.
Yes, it appears as if the integration is working. The entities do simply, or not simple, not represent the actual state of the mopidy instance.
I have similar problems since the last ha update: Pressing „Play“ in Home Assistant plays music on my separate mopidy server but ha doesn’t change to „playing“. General speaking, I reckon that ha doesn’t receive mopidy states any longer.
I only get the following error in ha regarding mopidy and I don’t know whether it is related to this issue or not
`
homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/commands.py:238
Integration: Home Assistant WebSocket API ([documentation](https://www.home-assistant.io/integrations/websocket_api), [issues](https://github.com/home-assistant/core/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+websocket_api%22))
First occurred: 11:37:38 (8 occurrences)
Last logged: 22:46:42
[546874781120] Entity media_player.mopidy_http_server_on_schlafzimmer_soundstation_6680 does not support this service.
`
I apologize in advance as I am no python dev but I browsed the ha dev blog for any breaking changes in the field of media player integrations. The only recent blog posts I found were the once stating that the old const values were depreciated.
see e.g. https://developers.home-assistant.io/blog/2022/09/06/media-player-repeat-mode-deprecation
No, it is a separate host running mopidy. I am running version 3.4.1-3. I can access mopidy in my browser. The funny thing is, that mopidy is accepting calls from HA, I can use it in automations as usual, but not as a trigger, since it is always unknown.
I've a similar setup (Mopidy 3.4.1 on a separate host than HA) and have the same problem. Generally, I'm able to turn on mopidy from HA using a service. However, usually, I'm turning on and off mopidy (radio station) with one button remote, and to be able to distinguish what should be triggered now (to turn it ON or turn it OFF) I need to check the current mopidy state, which since yesterday is 'unknown' instead of 'playing'.
Apologies for the delay, but I am currently away without computer. I should be able to properly fix it on monday
I apologize in advance as I am no python dev but I browsed the ha dev blog for any breaking changes in the field of media player integrations. The only recent blog posts I found were the once stating that the old const values were depreciated.
see e.g. https://developers.home-assistant.io/blog/2022/09/06/media-player-repeat-mode-deprecation
This was handled in my v2 release.
We seem to have gone off on a tangent.
What I'm seeing as of my update to 2024.1.0 is:
1. The media contol cards on my dashboards for my Mopidy server intially just greyed out and would not load. Removing the Mopidy intigration and re-adding it (using the GUI only, but with a restart each time) mostly resolved this; but 2. Since then the media contol card always shows the status as playing (with a pause button). After pressing this pause button playback does pause and two items apear in the Home Assistant Logboook * PiBMopidy became unavailable triggered by service Media Player: Pause * PiBMopidy changed to Playing triggered by service Media Player: Pause
Ultimatly "pause" didn't change the "playing" state accoring to Home Assistant -- but the music did pause.
I can still start/stop/pause my "PiBMopidy" using a mobile app or using scripts / automations fine but the Media Player card does not change or update. I cannot restart play using a "pause" button. Choosing new a new track using the Meida Control card does work (it starts playing the new track) but the track information does not update.
My Mopidy instance is sperate to the Home Assistant device. It is running "Mopidy 3.4.2" and seems to work normally aside from the recent quirk when reduced functionally when using Home Assistant Meida Player cards.
Thanks for the writeup, this really helped me figuring out the root cause. I did not update to HA 2024 yet, so I did not experience it.
I did some looking around, and figured out the state
method in media_player
changed from property
to cached_property
. I have no idea of the implications of this change (beyond braking my integration), but I definitely want to leverage this someway.
First a bugfix to get ths working for you guys, then figure out how to embrace the cached_property
...
keep you guys posted
@dflvunoooooo , @KingTeppic , @haind30bg, @dikt1338 , @wapacz I've drafted a new release: 2.2.2 Tested it at home and seems to work properly
Can confirm it's working
Yes, I can confirm too that it's working. Great thanks @bushvin
Hello, I had not noticed the integration breaking in 2024.1, but I have been getting lots of warnings about the image_url
. It logs the warning about every 10 seconds, since I restarted HA yesterday it's already logged 27k warnings about this.
I'm just using it to listen to internet radio, which don't have images.
Is this just an inherent problem of listening to radio streams, or could images be ignored somehow when listening to radio?
It works again. I can control mopidy using the integration. However there are still two issues, as far as I can see:
Update: The following services of domain media_player don’t work using the fix: toggle, turn_on, turn_off
Update: The following services of domain media_player don’t work using the fix: toggle, turn_on, turn_off
Will check
Hello, I had not noticed the integration breaking in 2024.1, but I have been getting lots of warnings about the
image_url
. It logs the warning about every 10 seconds, since I restarted HA yesterday it's already logged 27k warnings about this.I'm just using it to listen to internet radio, which don't have images.
Is this just an inherent problem of listening to radio streams, or could images be ignored somehow when listening to radio?
The image_url
warning is by design, but seeing there is some commotion about it (see earlier in this thread), I'll see if I can omit it when the media playing is a stream.
The new version works in my HassOS.Thank you very much, @bushvin!
Update: The following services of domain media_player don’t work using the fix: toggle, turn_on, turn_off
my apologies, @dikt1338 , for my tardiness
turn_on
and turn_off
are no longer available (and thus also toggle
) since v2
The reason for this is that these services are for physically turning on and off a device. Which mopidy is not.
I have drafted a new release to get rid of the image_url
warning.
I'll be closing this now.
This integration does not seem to work after updating. There is no real error message in the logs, but all three mopidy entities are unavailable. The only mention of mopidy in the logs is
No image_url found for https://…
, but this is only a warning.