AirPlay doesn't always start

[UKenGB]

I have several radio stations set up in MA that access streams from Rocket Streaming Audio Server (like Icecast) on the same machine. This all works. But…

Trying to control it from Home Assistant and it's unreliable. Using some test scripts or an actual Media Player card (not using the scripts) in HA it usually works as it should, but sometimes just doesn't play.

Watching the RSAS logs I can see that the MA server has connected to it and the requested radio stream is being provided.

I can also see in the MA web window that it gets the metadata of what the station is currently playing, but the MA server just doesn't start playing the stream. The controls at the bottom of the window still show the 'Play' icon so it knows it is not playing. If I click the icon it does play and the icon switches to the 'Pause' icon as it should and the station shown higher in the window shows it is actually playing.

I also notice that when it doesn't play, the HomePod Mini to which it is being sent shows correctly in HA (Developer/States) with all the attributes that should be available when playing, like what is playing etc. but I 'think' it still shows as 'Idle' and not 'playing' (need to confirm that).

So everything is set up to be playing, but somehow MA seems to have forgotten to actually start playing and I can see no reason why it works perfectly most times, but occasionally … 🙁

Is this the HA integration misbehaving or MA server?

Here's the MA log:-

`2026-01-27 10:30:47.635 INFO (MainThread) [music_assistant.airplay] AirPlay device connected. Starting playback.
2026-01-27 11:04:20.418 INFO (MainThread) [music_assistant.airplay] AirPlay device connected. Starting playback.
2026-01-27 11:04:43.489 ERROR (MainThread) [aiohttp.server] Error handling request from xxx..xxx.xxx.xxx
Traceback (most recent call last):
File "/app/venv/lib/python3.13/site-packages/aiohttp/web_protocol.py", line 408, in data_received
messages, upgraded, tail = self._request_parser.feed_data(data)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "aiohttp/_http_parser.pyx", line 556, in aiohttp._http_parser.HttpParser.feed_data
aiohttp.http_exceptions.InvalidURLError: 400, message:
Invalid char in url query:

b'GET /imageproxy?provider=builtin&size=500&fmt=jpeg&path=http://(path to channel logo file).png\x08 HTTP/1.0'
                                                                                                                                            ^

`

The first line (@10.30) is when it did NOT play (although it says it did). I stopped it shortly after.
The next line (@11.04) was successful and it started playing, but having trouble with images. Is this perhaps because the stream does not provide any image metadata? That error is repeated half a dozen or so times.

It is indicative that when it fails to start, there are no attempts to get image data, which all points to it not having actually started playing.

Hope this can help find the source of the problem as the intended purpose is to play the radio stream as an alarm and if it sometimes doesn't play, that's something of a problem.

BTW, I've been using the RSAS streams as an alarm (using a different mechanism) for many years now and unless there are any extraneous circumstances, it has been 100% reliable. So it's not a problem with the RSAS streams.

[OzGav]

Confirm that if you go to the station in the MA UI it always plays without problem? What is the format of the stream? Have you tried different formats if that is an option?

[UKenGB]

Ah, no it does not. I have not used it much from the web interface and hadn't noticed the problem exists there.

I just tried playing (in web UI) the same station I managed to play earlier and it played. I then tried a different station I have not played for days and despite RSAS showing it had been accessed and was providing the stream, MA did not start playing and I can confirm that the MiniPod status in HA did change from 'off' but then remained 'idle'.

I tried again, same problem. On the third attempt it played perfectly. In fact any stream that fails, will eventually play if I try again. I think 2 retries is the most I've seen.

They are all AAC streams and nothing has ever had any difficulty playing them so it seems unlikely to be codec used.

However I did then try several MP3 streams and they played right away. Then a couple of different AAC streams and they played no problem.

So basically, it is MA server that has the problem, but I still can see no obvious reason why.

[OzGav]

Yeah you will need to narrow down the problem, If it always plays MP3 but not AAC that is a start. Then I would look if there are different bit rates or anything you can adjust to further narrow down the issue.

[UKenGB]

I'll keep checking, but I wouldn't say it always plays MP3. It did the couple I tried, but then so did several AAC streams and also then the AAC stream that initially had a problem, but which played perfectly when I tried again. How could the stream format affect this? Seems to me there would be a problem playing a particular stream, or not, but not apparently randomly able to play it or not. Are you aware of something within MA that might be affected by this?

As I said I'll keep checking but the majority of times it plays. I haven't figured out any way to force it to happen.

[UKenGB]

There is some odd interaction between MA and RSAS (streaming server).

I have a radio station set up in MA whose URL is the RSAS stream and it consistently will not play. RSAS reports the connection but it's immediately dropped and with 0 listeners, RSAS stops the relay stream, so if you tell MA to 'play' it reports an error as there is no stream for it to play.

I then set up another MA radio that points to the actual Internet URL of the station and it plays - usually. After many successful plays it then wouldn't play, but since the stream did still exist, I was able to press MA's 'play' button and it started.

So all too inconsistent to be of much help.

What I have noticed is that when MA does actually manage to play, there is a glitch within the first couple of seconds where it seems to stop then start again. I put this down to a volume effect, but is it possible that MA connects to the stream but for some reason almost immediately drops it, then starts it again? Could random variation in the timing of this glitch cause a stream supplier to think MA has disconnected and so stop the stream? This does seem to be the problem when accessing RSAS (some source streams more likely to be affected).

What causes RSAS to see MA sometimes almost immediately disconnecting? Is this also occurring with the Internet URL, but the source simply takes longer to drop the stream?

Just guessing basically, but it is something MA is doing. In all these tests, whatever URL I'm trying to use in MA plays perfectly in VLC, ALWAYS and in the years I've been running RSAS in this way, no other client has had this problem, EVER.

Not blaming, just trying to get to the bottom of this and to my mind it is all pointing to MA. Do you want me to post MA logs of a failed attempt?

[OzGav]

Yes. Get a clean log by restarting the MA server and then do the minimum required to have this happen.

[UKenGB]

Back looking into this and updated to 2.7.11. No idea if that changed anything, but things seem better. The station I was having problems with has started every time I tried it and all stations I've tried do seem to start more promptly and without that glitch I was experiencing.

I'll keep testing, but fingers crossed. 🤞