Announce not working

Hi,

I’m getting started with announcements. I have a Lyrion Media Server running and a bunch of Squeezebox Radios spread through my home. I thought I’d start simple by using the developer tools > actions screen. Here’s the YAML that I entered:

action: media_player.play_media
target:
  entity_id:
    - media_player.keuken
    - media_player.squeezebox_radio_3
data:
  media_content_type: music
  media_content_id: media-source://ding-dong.mp3
  announce: true

Of course, I made sure there is a file called ding-dong.mp3 in my /media directory. (I’m using Home Assistant OS, so this should be the right directory.)

When I do this, my Squeezebox radio device displays some message that it can’t playback this playlist. So something is happening. Where do I start debugging what’s wrong? I already tried converting the file to .m4a, but that didn’t make any difference.

Try the following:

action: media_player.play_media
target:
  entity_id:
    - media_player.keuken
    - media_player.squeezebox_radio_3
data:
  media_content_type: music
  media_content_id: media-source://media_source/local/ding-dong.mp3
  announce: true

Just FYI, the announce feature doesn’t seem to be working on all combinations of integrations and hardware currently, so you may not get an announcement sound before “ding-dong.mp3” is played.

Thanks a lot! That was the missing piece. It was in the docs, but I thought it was just an example.

Hi @Didgeridrew . You mentioned that announce doesn’t work on “all combinations of integrations and hardware”. Did you mean Squeezebox devices or other integrations only? I haven’t come across any problems with Squeezebox, so would be grateful if you’ve come across any problems there - I wrote the announcement functionality for Squeezebox so want to make sure we get it working as well as possible

In general though, yes, you’re right. Announce is only supported by a small number of integrations at the moment - Squeezebox, Sonos, B&O is about it I think (although there may be others of course).

That was more of a general warning, not specific to any particular integration. I don’t use LMS (I moved to Music Assistant a while ago) nor have I seen any specific comments here on the forums about it not working with that combination, so I can’t say whether announce will work for you.

Thanks for the confirmation. As I mentioned, announce hasn’t been widely implemented - it’s something that each integration owner has to build into the integration. Sonos and B&O have an “overlay” type function in their API, so announce uses that. With Squeezebox, we just had to build it manually, but it works pretty well - apart from a slight conflict with fade-in (i.e. if you have fade-in enabled, it’ll fade in the announcement), but there’s nothing I can do about that one. As far as I know, that’s it - none of the other media players seem to support MediaPlayerEntityFeature.MEDIA_ANNOUNCE, which is the feature we enable to tell HA that we support announce.

1 Like

I can confirm that it works with LMS on my Squeezebox Radio devices.

1 Like

Thanks for the detailed info, @psketch! And even more thanks for implementing this in the LMS integration. It’s awesome!

No problem - pleased to help. We’re trying to make the integration the best it can be :slight_smile:

2 Likes

@psketch I’ve been experimenting with the announce feature a bit. Most of the time it works as expected, but I noticed some glitches:

  • Sometimes, it takes very long after the announcement before normal playback resumes.
  • Sometimes, playback does not resume, or it resumes playing a playlist that I played before the current one.
  • It creates a tempplaylist_[randoom_numbers] playlist when an announcement happens, but it seems those are not always cleaned up.

Are these known issues? Is there anything I can do if this happens?

Hmmm… Okay…

  • Sometimes, it takes very long after the announcement before normal playback resumes.

We’re basically waiting for the LMS server to tell us that it’s finished playing the announcement - i.e. going back into a stopped state is what we look for. Is the issue linked to certain announcement files, or just random? You can set a max for the wait time by specifying the announce_timeout setting - take a look in the doc for the format.

  • Sometimes, playback does not resume, or it resumes playing a playlist that I played before the current one.

Not seen that one. Anything that helps investigate - is it reproducible or is ther a pattern?

  • It creates a tempplaylist_[randoom_numbers] playlist when an announcement happens, but it seems those are not always cleaned up.

Are the random numbers random, or is it the mac address of the player? What’s in the templaylist - is it the previous playlist, or is it creating a temp playlist for the announcement? Again, any pattern?

Is the issue linked to certain announcement files, or just random?
I’ve only used two announcement files so far, and I’ve seen issues with both. Other than that,

I did not yet notice any patterns.

You can set a max for the wait time by specifying the announce_timeout setting - take a look in the doc for the format.

Thanks for pointing that out. I think setting a timeout that’s only slightly longer than the length of the announcement should work.

Not seen that one. Anything that helps investigate - is it reproducible or is ther a pattern?

I’ve not experimented long enough to observe any patterns. I’ll keep using it and see if I can find patterns.

Are the random numbers random, or is it the mac address of the player?

Could very well be a mac address, but didn’t verify that. When I opened the playlists, they contained what looks like the playlist that was playing when I triggered the announcement. I’ll try to detect patterns. For my understanding: the numbers should be the MAC address of the player? And should they be cleaned up after playback resumed? Or do they not get cleaned up but are reused instead?

Yep - it should be the mac address. When I save the current playlist, it will always save the current playlist into tempplaylist_macaddress. That would perhaps also explain the replaying the earlier saved list - if it didn’t delete the list from earlier, it perhaps won’t overwrite it with the new one - so you get the previous list.

When we want to resume, I do

        await self.async_command(
            "playlist",
            "resume",
            f"tempplaylist_{self.player_id.replace(':', '')}",
            f"noplay:{0 if self._saved_state['mode'] == 'play' else 1}",
            "wipePlaylist",
        )

The wipePlaylist param is …

wipePlaylist` , which will destroy the saved playlist from both the filesystem and from the DB (these tagged params are typically used for resuming a temporarily cached playlist, e.g. after exiting alarm sound preview on squeezeplay devices).

So, sometimes that command is failing (no resume) or not wiping the saved list. Next time you get it, could you have a look in the system log and see if there’s any errors. I’m guessing the LMS might not have sometimes be happy deleting the playlist when it’s just finished playing something, but not sure why. I can add a couple of small delays, but let’s see if the logs tell us anything.

I’ll see if I can find any useful logs next time it happens.