I'm using Squeezebox (Lyrion Music Server) and I have this trigger to play sound on all speakers when door opened and it's working fine until yesterday when I updated my HomeAssistant from few months ago to recent version.
input_text.cs is all of my ceiling speakers entity_id, previously it will play to all speakers at the same time but now it will play one by one. Anyone know what changes? I checked the changelog and can't seem to find anything related to media_player or Announce
class DoorAutomation:
wk2kc_door_open_sound_is_playing = False
@state_trigger("binary_sensor.ds_wk2kc_contact == 'on'")
def wk2kc_door_open_sound():
if DoorAutomation.wk2kc_door_open_sound_is_playing:
log.info('wk2kc_door_open_sound is playing, aborted')
return
DoorAutomation.wk2kc_door_open_sound_is_playing = True
for media_player_eid in input_text.cs.split(','):
media_player.play_media(
entity_id = 'media_player.' + media_player_eid.strip(),
media_content_id = "media-source://media_source/local/FamilyMart Chime.mp3",
media_content_type = "music",
announce = True,
extra = {
"announce_volume" : 0.5
}
)
task.sleep(6)
DoorAutomation.wk2kc_door_open_sound_is_playing = False
Note that I also tested using regular YAML and in developer tools and the same thing happened. If I trigger media_player.play_media with announce = true on Speaker A and before the sound ended, if I trigger another media_player.play_media on Speaker B. It will wait until Speaker A finish before playing B. Why is this happening?
Without announce = true, Speaker B will play as soon without waiting for Speaker A
Do you know what version you updated from? I've got no idea what might be causing this to tbh, but it would be good to know a start point and I'll try and figure out what's changed, although I don't recall changing much recently.
There have been gradual changes to i2s audio and anything related to it over the past year. There are still more changes ongoing. What it sounds like is basically the call is blocking now, so you'd want to queue the calls instead and then play them. Haven't tried it, but would that would be my next attempt to see how it turns out.
Hello, may I ask what do you mean by queue the calls? My use case is that I use ceiling speakers for alarm, doorbell, etc. So as soon as someone press the button, it should play the sound immediately instead of queue the playlist (if that's what you mean by queue), hence the need of announce=true
Wrap your call to media_player.play_media in task.create(), or probably way easier, remember that you can pass multiple entity id's in a single call. You're looping through each one sequentially when it would be far easier to just build a list of your entity id's and pass it to a single play_media call and then HA would handle passing it out to each device.
Can't guarantee it'll play at exactly the same time, but it should be close to what you're expecting.
We've hardly made any changes between April and now tbh, and nothing around announcements or queues. TBH, each media player is a separate instance underlying class so I can't see anyway they could impact each other. My guess is that something must have changed in the way that HA is dispatching the calls, but I haven't seen anything - i.e. it feels more like a core problem than specific to the integration - each media player instance just processes the instructions it receives when it receives them, so if they're being queued this must be at the HA server level I think. I'll try and do some testing over the weekend but don't think this is likely on the integration side.
Feel free to open an issue. It'll get tagged with Squeezebox so assigned to us, and then we can remove the tag if it turns out to be core.
OK - found it. There's a restriction we can add which controls the number of parallel calls passed to the API - so we don't flood the server for any reason. It's currently set to 1. Somewhere after 2026.4.1, they must have expanded the impact of this to cover these actions and the doc actually reflects that. I'll take a look if we can unrestrict this.