SiriusXM requires hitting the blue play button twice to cast a station

[nikito]

What version of Music Assistant has the issue?

2.4.0b4

What version of the Home Assistant Integration have you got installed?

2024.11.2

Have you tried everything in the Troubleshooting FAQ and reviewed the Open and Closed Issues and Discussions to resolve this yourself?

• Yes

The problem

When selecting a SiriusXM Radio Station and selecting Play to cast it to a Chromecast Player, the first press results in the station casting to the device but being stuck buffering. Clicking the blue play button again (requesting to play again) then makes it work.

How to reproduce

Select a SiriusXM Radio station and hit the Play on Device button. It will buffer but not play. Hit the play on device button again and it will then start playing.

Music Providers

SiriusXM

Player Providers

Chromecast

Full log output

music-assistant.log

Additional information

No response

What version of Home Assistant Core are your running

2024.11.1

What type of installation are you running?

Home Assistant OS

On what type of hardware are you running?

Generic x86-64 (e.g. Intel NUC)

[OzGav]

@btoconnor

[btoconnor]

Gonna be a little bit before I can take a look at this.

What I'll say is that the SiriusXM provider simply passes along a m3u8 url to the MA core. If there's a timeout coming from the client on the first attempt, we'll have to look at configuration parameters to see if we can increase the timeout, but it's not clear why the second attempt would succeed - maybe race condition or buffering or something?

[btoconnor]

I think I have an idea of what's going on here, but not 100% on the best path forward.

I think what's happening is - when MA starts, it authenticates with the sxm-client in order to sync the channels available. However, these authentication sessions are short lived, and the client must continue to re-authenticate on some interval. The client handles this automatically in the background when streaming music as it continues to refresh the m3u8 playlists.
By the time the user clicks to play a station - the session has expired, and the client must re-authenticate. This happens automatically, but by the time the session is re-established, ffmpeg appears to be treating the delay as a timeout since it hasn't received any data yet.

When the user clicks play again, they still have an authenticated session with sxm-client, and it can stream.

There's a few potential options I can see moving forward:

1. Explicitly re-authenticate the session when the user chooses a station. Pretty straightforward. I don't think we'd need to even check if it's expired first.
2. Increase the timeout with ffmpeg somehow with siriusxm when starting a station. As I type this out, I don't like this option as much.

[OzGav]

2.3.4 has been released with the fix. Beta to follow. Confirm this has been rectified.

[OzGav]

beta 8 has been released. This will be closed soon assuming fixed

[nikito]

Appears fixed for me. 🙂

Edit: just ran into the issue just now. Had to issue the command twice for it to work. Didn't see anything interesting in the log, but it may be worth noting the player i was trying to play the station on was a Chromecast with queue flow mode turned on.

[nikito]

Also just had the issue occur on a non flow mode Chromecast payer as well, so seems to not necessarily be caused by that.

[Dnugs]

adding here that I’m running the latest docker image (2.3.4) and this same behavior occurs when streaming to an airplay device. Need to hit play twice, sometimes hitting it the 2nd time results in a stream that is very low quality or garbled. Pausing or turning the player on/off again and hit play a third time tends to reliably produce a good stream.

[Doug411]

Same behavior using Chromecast player, flow mode off, and running HA Add on server 2.40b17