alandtse / alexa_media_player

This is a custom component to allow control of Amazon Alexa devices in Home Assistant using the unofficial Alexa API.
Apache License 2.0
1.44k stars 275 forks source link

Media Players Not Updating #1953

Closed broyuken closed 11 months ago

broyuken commented 1 year ago

IMPORTANT: Please search the issues, including closed issues, and the FAQ before opening a new issue. The template is mandatory; failure to use it will result in issue closure.

Describe the bug

Media Player entities go stale after a few hours. If I start playing media either with my voice, or by having a routine triggered my HA media player entities don't know about it and just says standby. Or if media has been playing for a while and I stop it, the media player entity will still show it playing. Reloading the integration with kick things and get them showing the correct status again for a little while To Reproduce

  1. Play media on an alexa device after it's been idle for a few hours.
  2. Observe media state in HA hasn't changed
  3. Submit issue on github

Expected behavior

Media player should show current status of media player entities Screenshots

System details

Logs Please provide logs. These debug logs begin at 9:08 when I run my "soundmachineon" routine which plays white noise on amazon music and didn't update the status until 9:09 when I reloaded alexa media player. Ignore the BROKEN_TUYA lines, they were filling up my logs so I did a find/replace to get rid of them.

alexa_logs.txt

broyuken commented 1 year ago

@alandtse is there anything additional you need me to provide to look into this further?

alandtse commented 1 year ago

The logs indicate that websocket is reporting data, the player urls are being queried, and you're not getting errors to the requests. Please note that not all services actually update the player. Check the official app and see if it's actually displaying what's playing.

broyuken commented 1 year ago

Yes, but the logs also show that the routine starts which just plays white noise from Amazon’s music, but the status of the player never updates. The official app does show that update, and reloading the integration updates the media player and then everything is fine…for a couple hours.

emufan commented 1 year ago

Can confirm here as well. There is in these cases not error in the log, nothing. And state of player is Standby but this state state is then hours old.

But if I try via TTS to call it, nothing is happening. Only if I restart the integration and try it again.

And even if I start e.g. a timer via voice on the device itself, the next_timer-entity stays in "unknown". And only if I restart the integration, the next_timer-entity would be filled again.

broyuken commented 1 year ago

I just checked this morning and the Alexa app shows that it is playing, and when I say Alexa stop, it shows it paused. In HA however it still shows it playing. If I reload the component it will update correctly.

broyuken commented 1 year ago

Just saw this when I try to pause it in HA when it’s already paused in real life.

Source: custom_components/alexa_media/media_player.py:1170 
Integration: Home Assistant WebSocket API (documentation, issues) 
First occurred: 6:21:51 AM (2 occurrences) 
Last logged: 6:21:59 AM

[140630914232624] 'NoneType' object has no attribute 'data'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 199, in handle_call_service
    await hass.services.async_call(
  File "/usr/src/homeassistant/homeassistant/core.py", line 1849, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1889, in _execute_service
    await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 226, in handle_service
    await service.entity_service_call(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 798, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 980, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 838, in _handle_entity_call
    await result
  File "/config/custom_components/alexa_media/helpers.py", line 156, in _catch_login_errors
    result = await func(*args, **kwargs)
  File "/config/custom_components/alexa_media/media_player.py", line 1163, in async_media_pause
    await self._playing_parent.async_media_pause()
  File "/config/custom_components/alexa_media/helpers.py", line 156, in _catch_login_errors
    result = await func(*args, **kwargs)
  File "/config/custom_components/alexa_media/media_player.py", line 1170, in async_media_pause
    self.hass.data[DATA_ALEXAMEDIA]["accounts"][self._login.email]["websocket"]
AttributeError: 'NoneType' object has no attribute 'data'
steff75 commented 1 year ago

I have found that it is usually enough to perform a media player action (media_next_track, volume_up, ...) when it hangs. Then the dashboard player status mostly updates immediately. A restart of the integration was not necessary for me so far.

broyuken commented 1 year ago

I just called the volume down and volume up services but it still shows it in standby. Official Alexa app shows the white noise audio track playing off Amazon music.

alandtse commented 1 year ago

Just saw this when I try to pause it in HA when it’s already paused in real life.

This error indicate HA is broken for the integration. Every integration is supposed to have access to the hass.data object automatically. If it doesn't, then there is something very wrong. There is no way to solve the issue short of a reload of the integration where hopefully HA provides the entity. Assuming you're not getting that error, then you should confirm you're seeing websocket traffic. You can test this by enabling debug logging and then manually changing the volume button. If you're not seeing websocket, then the integration cannot update info without directly using HA to interact with the component.

broyuken commented 1 year ago

I was trying to make sure things were broken before I started the debug logs and I found something interesting. If I call my routine from within HA using a service call from a card like this or from an automation, I can see the volume adjust on the lovelace card, but the state still shows standby.

type: custom:mushroom-entity-card
entity: script.music_sound_machine
name: Sound Machine
tap_action:
  action: call-service
  service: script.music_sound_machine
  service_data:
    volume: 0.6
    device: media_player.charlottes_echo_spot
  target: {}
icon: mdi:sleep
secondary_info: none
layout: vertical
fill_container: true

However if I go into the alexa app on my phone I can see the media player in a playing state. Then if I hit pause in the alexa app, the lovelace card updates showing it's paused.

Once it breaks again I will try to enable debug logging and see what happens.

broyuken commented 1 year ago

It broke again, and here are some logs. I started my goodnight routine around 2023-06-06 21:02:10.306, but the logs never show the state updating from standby, it always stays . The alexa app shows the stream playing as an active media source, and if I was to pause it (I didn't because it would wake up my wife) it would trigger HA to notice that it's playing. I tried changing the volume with both service calls and from the HA app, but neither of those triggered the state change.

These are the raw debug logs minus the local tuya stuff I removed from there because it is log spam that I need to fix when I find the time. The other errors you see in there are spotify went funky earlier today and one of my roborocks is offline because it's being replaced: home-assistant_alexa_media_2023-06-07T01-06-47.569Z.log

I should also note that I am currently on 2023.6.0b5, but was running into the same issue under 2023.5.x, and maybe even 2023.4. Before that it would happen occasionally but now it's not even close to reliable.

alandtse commented 1 year ago

Your websocket is reporting changes but doesn't appear to report anything after your routine is run. If this worked before, it looks like the websocket isn't broadcasting any state changes now so it's an API change. There's nothing I can do to capture this unless after every routine I turn on polling for all alexa devices. That will likely be very spammy and I have historically not enabled polling unless there's actually a play command issued by a media player.

That said, due to the restart, the component does try to make one attempt to see if things are playing. In this case for the device where it appears you issued the request this is the response and it didn't see anything playing per amazon. Are you positive the App or webplayer actually shows white noise content when playing?

2023-06-06 21:06:33.897 DEBUG (MainThread) [alexapy.alexaapi] d***********6@y*******m: Trying get: https://alexa.amazon.com/api/np/player?deviceSerialNumber=SNIP&deviceType=A4ZP7ZC4PI6TO&screenWidth=2560&_=1686099993897 : with uri: /api/np/player data None query {'deviceSerialNumber': 'SNIP', 'deviceType': 'A4ZP7ZC4PI6TO', 'screenWidth': 2560, '_': 1686099993897}
2023-06-06 21:06:34.072 DEBUG (MainThread) [alexapy.alexaapi] d***********6@y*******m: GET: https://alexa.amazon.com/api/np/player?deviceSerialNumber=SNIP&deviceType=A4ZP7ZC4PI6TO&screenWidth=2560&_=1686099993897 returned 200:OK:application/json
2023-06-06 21:06:34.074 DEBUG (MainThread) [custom_components.alexa_media.media_player] d***********6@y*******m: Refreshing <entity None=standby>
broyuken commented 1 year ago

I am 100% positive the Alexa app shows white noise playing.

broyuken commented 1 year ago

Are there any other logs I need to provide to help you track this down?

broyuken commented 1 year ago

Checking in on this again. Is there anything else you need from me to help move this along?

broyuken commented 1 year ago

@alandtse is there anything else I can provide to help solve this issue?

alandtse commented 1 year ago

Please don't ping me. I don't promise any support. The code is open and you can make your own changes. I've already analyzed your logs and explained what I know. Honestly, I'm probably done with supporting this and pings do not encourage me to work more.

emufan commented 1 year ago

I would completely understand and as you said open code, etc. But I cannot do such codings and have the not-updating-anymore as well. So any mitigation oder fix on the long run would be very very good of course.

Here e.g. die next-timer entities often are not started and stay as unavailable even when a timer on the device is started. Only a reload of the integration is fixing this then.

broyuken commented 1 year ago

Sorry for pinging you, the only reason I did was because I sent a few messages with responses to your question and didn’t hear anything back. The app shows it playing, HA does not.

Is there anything we can do as non coders to help you try to figure out what may have changed in the api? We can’t be the only two people having this issue.

@emufan couple questions,

  1. What type of WiFi APs do you use?
  2. What type of echo devices are you seeing this issue on?

for me I use Unifi WiFi 6 Lites and am seeing this issue in particular on an echo show 5 and an echo spot. Those are the two devices I run the sound machine on, but I “think” the issue occurs on them all.

emufan commented 1 year ago

AVM Fritz Repeater 2400 and Wchoe Show 5.

krisnoble commented 1 year ago

Does running homeassistant.update_entity on the relevant media_player entity help at all?

broyuken commented 1 year ago

That’s a great question, I’m not home this weekend but I’ll test that out when I get back.

jlong23 commented 1 year ago

Sorry for pinging you, the only reason I did was because I sent a few messages with responses to your question and didn’t hear anything back. The app shows it playing, HA does not.

Is there anything we can do as non coders to help you try to figure out what may have changed in the api? We can’t be the only two people having this issue.

@emufan couple questions,

  1. What type of WiFi APs do you use?
  2. What type of echo devices are you seeing this issue on?

for me I use Unifi WiFi 6 Lites and am seeing this issue in particular on an echo show 5 and an echo spot. Those are the two devices I run the sound machine on, but I “think” the issue occurs on them all.

Same here. I suspect it's issues with Ubiquity's MDNS implementation, I have issues with WEMO Switches on the network too. I will restart the UnifiServices and see if the Polling works with the Dots/Echos and if HA can see the WEMOs too

broyuken commented 1 year ago

I have issues with my printer as well where it’s unavailable for AirPrint unless I do a reconnect on it in the unifi app.

RSpeekenbrink commented 1 year ago

Does running homeassistant.update_entity on the relevant media_player entity help at all?

This did it for me, had the same problem, but manually pinging an entity update does the trick.

RSpeekenbrink commented 1 year ago

Does running homeassistant.update_entity on the relevant media_player entity help at all?

This did it for me, had the same problem, but manually pinging an entity update does the trick.

This does not work with the alarm/timers etc tho, they are all still on unknown

jlong23 commented 1 year ago

Does running homeassistant.update_entity on the relevant media_player entity help at all?

This did it for me, had the same problem, but manually pinging an entity update does the trick.

This seems to help, kept updating the entity from that point while playing, stopped playback and started a new Pandora Session and it still updated. Will play if we need to schedule the service call for periodic refreshing of the 7+ AMZ Devices

krisnoble commented 1 year ago

Does running homeassistant.update_entity on the relevant media_player entity help at all?

This did it for me, had the same problem, but manually pinging an entity update does the trick.

This does not work with the alarm/timers etc tho, they are all still on unknown

Just checking, you're running the update service on the relevant sensor entity rather than the media_player? That works for me although could be one of those temperamental ones where sometimes it works, sometimes it doesn't.

You can run the following in the developer tools template section to get a YAML-formatted list of all enabled entities from the integration - I can't figure out how to get it to work in the actual service call right now but you can copy-paste and save some typing at least...

{% for entity in integration_entities("alexa_media") %}
- {{ entity }}
{%- endfor %}
krisnoble commented 1 year ago

Does running homeassistant.update_entity on the relevant media_player entity help at all?

This did it for me, had the same problem, but manually pinging an entity update does the trick.

This seems to help, kept updating the entity from that point while playing, stopped playback and started a new Pandora Session and it still updated. Will play if we need to schedule the service call for periodic refreshing of the 7+ AMZ Devices

Yeah, I have something like the following running, not sure if overkill but seems to run okay and keeps things updated:

alias: Alexa media updates
description: ""
trigger:
  - platform: homeassistant
    event: start
condition: []
action:
  - repeat:
      while:
        - condition: template
          value_template: "{{ true }}"
      sequence:
        - service: homeassistant.update_entity
          data: {}
          target:
            entity_id:
              - < list of entities >
        - delay:
            hours: 0
            minutes: 0
            seconds: 10
            milliseconds: 0
mode: restart
jlong23 commented 1 year ago

I left the dot idle for a few hours and started a new Pandora session, didn't update until I called the service: homeassistant.update_entity data: {} target: entity_id: media_player.computer_room_dot

Suspect that it falls off the polling when idle for a while.

Will implement the suggested trigger that @krisnoble posted, probably set it for repeat at 1 min as my use-case is watching / recording the current song played on Pandora when I am in the shower.

emufan commented 1 year ago

but manually pinging an entity update does the trick.

But where is the trick, if I don't know, when a timer is running. You are suggesting, to poll/ping every entity periodically e.g. every 1 minute 24/7? I don't know, if this is a good apprach.

jlong23 commented 1 year ago

You are suggesting, to poll/ping every entity periodically e.g. every 1 minute 24/7? I don't know, if this is a good apprach.

Agreed, but a production / user workaround is better than nothing. I would like a bit more control over the the HA Polling threads, or Ubiquity UDME not to loose fixed DNS entries when it shouldn't and forget ones when it should, no defects there ;)

The polling the monitored media_players is working for me ATM, 12% Utilization on the NUC style HA host (No noticeable Changes). So I am happy now that I can see my last ten items on my playlist dashboard.

krisnoble commented 1 year ago

You are suggesting, to poll/ping every entity periodically e.g. every 1 minute 24/7? I don't know, if this is a good apprach.

FWIW this is my system running in Docker on a Pi4 4GB, updating every 10 seconds. The raised periods are in the evenings when the Pi runs some other stuff like a slideshow and some custom scripts. Peak values are 58c, 19% processor, 56% memory, 1.4 load average, all well within nominal as far as I know. Hopefully that's reassuring?

Screenshot 2023-07-26 at 13 41 22
alandtse commented 1 year ago

FYI, the concern with excessive polling is that Amazon will throttle or block you. This is the reason we do not use that as a solution generally. But if you're ok with that risk, this may be a workaround.

DarkStarSword commented 1 year ago

Agree with alandtse on that, however it should be noted that the risk could potentially extend beyond those who are using the workaround to all users of Alexa Media Player depending on what Amazon chooses to do about it if/when they notice.

Presumably the reason this broke in the first place was because Amazon was trying to reduce their API load and/or traffic and disabled broadcasting state changes to achieve that (or it could just be a bug and completely unintentional, but we have no way to know that). Now that some users are polling them for state that would increase their traffic rather than reducing it, and once they notice that and their investigation points to Alexa Media Player, they may either block the specific users, or may just block the entire app to stop the increased load.

The thing is, if they don't pay very close attention they may not even realise that it is only a few users causing it which means the chance that they block the entire app is higher than you might naively expect - however it is hard to say how big that risk actually is.

krisnoble commented 1 year ago

Good points both and apologies, I didn't realise the update polling wasn't purely local. I certainly don't want to cause any problems for anyone so I've dropped my polling down to once an hour for now which has been stable all morning as far as I know and should be much more reasonable in Amazon's eyes.

I was already planning to migrate from Alexa to something more open anyway, so that plan has just been shifted from "soon" to "now". FWIW though thank you Alan et al for all your work on this, it's been immensely helpful over the last few years and much appreciated.

Pirol62 commented 1 year ago

Hi, facing the same issue I'd like to refresh only the selected alexa group when music playing is active once a minute. Would that be acceptable?

- id: '206'
  alias: Alexa media player updates
  description: ""
  trigger:
    - platform: state
      entity_id: input_boolean.music_playing
      to: 'on'
  condition: []
  action:
    - repeat:
        while:
          - condition: template
            value_template: "{{ is_state('input_boolean.music_playing','on') }}"
        sequence:
          - service: homeassistant.update_entity
            data: {}
            target:
              entity_id: >
                {% set player = states('input_select.music_sources') %}
                {% set map = {
                  "Erdgeschoss": "media_player.erdgeschoss",
                  "Alle Etagen": "media_player.alle_etagen",
                  "Home Office": "media_player.home_office",
                  "Dinnerparty": "media_player.dinnerparty"
                }%}
                {{ map[player] if player in map else 'media_player.receiver' }}
          - delay:
              hours: 0
              minutes: 1
              seconds: 0
              milliseconds: 0
  mode: restart
Pirol62 commented 1 year ago

PS: I tested it over the weekend with 5 Minutes delay and it worked stable. Interestingly the media player obviously stops updating after 3 or 4 Minutes and only sometimes. So I will set the delay to 3 Minutes. That seem to be good in order to have an accurate display of the current state. By the way: The input_boolean is set by a script which starts the music via button press or alexa.

DarkStarSword commented 1 year ago

@Pirol62 While I can't speak for what thresholds Amazon deems acceptable, that looks like an entirely reasonable workaround to me to keep polling to a minimum while still allowing the desired functionality :)

energywave commented 1 year ago

I also have the same problem and I'm constantly being contacted from people that are using my multinotify that are having this issue that generates two issues:

Generally the "solution" is to reload the integration or restart Home Assistant but not having even a way to detect that this is happening is very bad.

From my perspective it could be that the websocket is closing without notice so it stops to receive updates from Amazon. I'm not a python programmer so I'm not able to contribute (sigh...) but couldn't anyone check the webserver management code? We could work on that to ensure the websocket is alive and if it's not we can reestablish it. As a last resort a code that every time interval recycle the websocket could be a temporary fix that helps this not to happen too frequently. But websocket closing should be a very detectable event that should be handled.

PaulBiod commented 1 year ago

Hi, I am experiencing the same bug, for some reasons, the media player state isn't updating at all, and only a reload of the integration can fix the bug, I don't know for how much time. This is really problematic because many automations depend on these states. I'm not a python coder but I wish someone will put his hands on it to fix it, cause this integration is so popular. Anyway, thanks to the author, and I hope this bug can be fixed in the future.

steff75 commented 1 year ago

I'm not sure if it's the same or at least a similar issue, but competitor addons have also had issues recently (ioBroker, node-red) after changes at Amazon. These are both dependent on the alexa-remote2 library, where the developer has now made some adjustments to make it work again temporarily.

energywave commented 1 year ago

.

Hello if that issue started recently I don't think it's the same as this issue is present from ever, years at least.

DarkStarSword commented 1 year ago

this issue is present from ever, years at least.

You sure about that? This ticket was only opened in the last few months:

image

I also only started encountering this issue around that time, give or take. If the issue existed before that perhaps something has made it get worse recently so more people started encountering it / noticing?

From my perspective it could be that the websocket is closing without notice so it stops to receive updates from Amazon.

That's not how I interpreted Alan's analysis of the log file, unless I misunderstood?

https://github.com/custom-components/alexa_media_player/issues/1953#issuecomment-1579807928

emufan commented 1 year ago

Here it starts only in May as well. But I have the feeling that it is getting even worse in the last days and week. My timers are now not updating anymore in 90%. Not when they are started and (this is new) not even when they are then finished/outdated.

energywave commented 1 year ago

this issue is present from ever, years at least.

You sure about that? This ticket was only opened in the last few months

Yes, I'm absolutely sure about that. There was previous issues about this argument that was closed, here the first I've found where I've participating in: https://github.com/custom-components/alexa_media_player/issues/1578 That's more than a year ago (and the problem was there from well before).

I also only started encountering this issue around that time, give or take. If the issue existed before that perhaps something has made it get worse recently so more people started encountering it / noticing?

I don't know why that problem arrives in waves, maybe when Amazon changes something then it happens more frequently, who knows. In fact if you don't use volume_level or timers, or play status of Alexa devices there a good chance you'll even not noticing this issue is there as it's not preventing announcements and other commands from being run. It makes status updates from Amazon not arriving so, for example, you change the volume of a device by voice but that volume in the Home Assistant entity don't change. I noticed that from much time as I've developed multinotify, a script that, between the other functions, backup the volume and play status of devices, play the announcement then restore the volume of every device and resume the play where it was paused. When the websocket stops working that script is backing up a not real status and that makes you understand to be in that condition easily.

From my perspective it could be that the websocket is closing without notice so it stops to receive updates from Amazon.

That's not how I interpreted Alan's analysis of the log file, unless I misunderstood?

#1953 (comment)

Yes, you're right. This could be a brand new issue with same symptoms that was there from ever. But stating that my Alexa devices are working as before (they update with the Echo devices status then, after a random amount of time, they stops updating) I thought that this issue was related to that condition that there from ages. Furthermore more than one users of my script told me about this issue and I suggested to reboot or reload the integration and that fixed that, until next time. So that's the exact same issue as ever.

UglyBob79 commented 1 year ago

Similar issue here, I got my Alexa devices a few weeks ago and I NEVER got the players to update state in Home assistant. I play music by telling Alexa to play and all media_player entities are still in standby. I have reinstalled the integration multiple times, nothing helps. I have an Echo Show 5, an Echo Studio and a Wiim Pro, none update status.

If I debug I see the commands I'm telling alexa, like for instance ...'summary': 'play music in living room', but all devices are always either in state standby or paused. This is driving me nuts as I can't turn on my AVR when playing music. So my setup is useless right now.

Is there anything I can do to help you help me find out why this isn't working? Can I manually querying the API somehow for instance?

emufan commented 1 year ago

I tested a lot and in the meantime not even homeassistant.update_entity is bringing information back for timers which are started but not available or finished but not deleted. Or better to say: not reliable updating. 80% not, 20% by chance yes.

But shouldn't it be 100% from a technical view? As it is not the case, I don't understand it completely anymore.

Pirol62 commented 1 year ago

I recently tested it, and you're right. I had to restart the component in order to refresh the alexa device and get the right information about a timer which I set before. There is something basic broken which is more then just the update of a media player device.

Pirol62 commented 1 year ago

Today I detected the first time, that timers are not updated anymore even after a restart of HA or refresh of entities.