Media_player.media_next_track fails repeatedly

Third party integrations
,
1

I have several automations that use the media_player.media_next_track action.

Over the past few days, this has failed several times. When this happens, I reload the media player integration and it starts working again — until the next morning.

I use this command on multiple buttons with multiple Echo devices, and media_player.media_next_track stops working on all of them, while other commands such as media_player.media_stop continue to work fine.

At one point, I even saw an error somewhere in HA saying something like: “media_player.media_next_track is not supported for your Echo XY.”

Has anybody had a similar experience or any idea what might be causing this?

In the meantime, I’ve created an Alexa routine so I can trigger a media player reload by voice.

I’ve also enabled debug logging now. Hopefully, I’ll be able to capture some useful information the next time it happens.

2

Update – likely cause found and workaround

I was able to reproduce the issue several more times with extended Alexa Media Player debug logging enabled.

It turns out that this is probably not a problem specific to media_next_track. When the issue occurs, media_next_track, media_previous_track and media_pause all stop working, while commands such as volume changes and media_stop continue to work.

The affected Echo also gets stuck in an apparently stale AMP state. For example, while Amazon Music is actually playing, Home Assistant may show:



state: idle
media_content_type: idle
supported_features: 318399
available: true

The extended debug log also showed that the HTTP2 connection itself was still alive. PUSH_VOLUME_CHANGE and other push messages were still being received and processed, so this does not appear to be a complete loss of the Alexa/HTTP2 connection.

What seems to happen is that the playback/player state for an individual Echo becomes stale in Alexa Media Player. In that state, the normal transport commands (next/previous/pause) no longer work correctly.

The important discovery is that reloading the complete Alexa Media Player integration is not necessary.

Calling homeassistant.update_entity for the affected Echo immediately restored the transport commands in my tests:



action: homeassistant.update_entity
target:
  entity_id: media_player.echo_4_lr

After executing this, media_next_track, media_previous_track and media_pause started working again.

I therefore changed my button automation so that, if AMP currently reports the Echo as idle, it first forces an update of that particular media player, waits one second, and then sends media_next_track:



- if:
    - condition: state
      entity_id: media_player.echo_4_lr
      state: "idle"
  then:
    - action: homeassistant.update_entity
      target:
        entity_id: media_player.echo_4_lr

    - delay: "00:00:01"

- action: media_player.media_next_track
  target:
    entity_id: media_player.echo_4_lr

This is much better than reloading Alexa Media Player because it only refreshes the affected Echo and does not disturb all other Echo devices.

One caveat: idle / supported_features: 318399 by itself does not necessarily mean that AMP is broken. An Echo that really is idle can legitimately have that state. I only use idle here as a practical trigger before sending a transport command. A forced entity update in that situation is harmless, and if AMP’s playback state is stale, it appears to repair it.

So my current conclusion is:

Likely cause: stale/out-of-sync playback state for an individual Echo inside Alexa Media Player.

Workaround: homeassistant.update_entity on the affected media_player before retrying the transport command. A complete AMP reload is not required.

I don’t yet know why the playback state becomes stale in the first place, so the underlying AMP/alexapy issue may still need investigation.