Homepod disconnects or stops playing music from itunes randomly

Ok a few things: the music cutting out is a connection issue, it doesn’t matter how fast your speed is or if other devices are working just fine. Homepod does not work well with Dual Bands Wifi. If you have that you need to disable the 5G and just use the lower speed and match that up with your device (the one you set it up with)

• Or you can try rebooting your wifi modem.

• Homepod needs a software update to 13.4 now - see if you can update it.
• Update your device or iPhone as well.

Not being a one to control it on your device, is the music App. You’re not using the iTunes app for this

This also might be the network not working on your iPhone for this. (rebooting the wifi and/or resetting network settings can usually resolve this issue)

• Some things you can try:

If the Music App isn’t responding 

Make sure your iOS software is up to date

• Close the music app- How to force an app to close on your iPhone, iPad, or iPod touch: https://support.apple.com/en-ca/HT201330
• in Settings- General - Reset - Reset Network Settings
• Restart your iOS device  (until the Apple logo appears)

I have had this same issue with iTunes and airplay to Homepod. 28 seconds into a track the sound stops followed by the "-" symbol next to the speaker in the list of connected devices. The sound comes back about 8 seconds from the end of the track and goes into the next song just to repeat the same. This does not happen 100% of the time but it is very common and the timing is always the same. You'll see in the attached picture all other Airplay devices are humming along. Only the office speaker has the "-" which is my Homepod. If I click on the minus, the sound comes back only to go back out 28 seconds into another song.

I have no bandwidth issues (Link rate is 866 Mbps to the Homepod). I've reset the homepod multiple times, restarted router, computer, etc. I've even flashed the bios on the off chance that something weird was going on there. The issue persisted.

I decided to try a brand new Homepod. It was on version 11.2.5 out of the box. After set up, I did not update it. Guess what...it played perfectly for over an hour. VICTORY! .......Unfortunately, it would not stay connected to the network when it was idle. I had to unplug it then plug it back in to get it to reconnect. I decided to update to 13.3.1 in hopes of correcting the connectivity issue and everything working fine with playback.

After updating, two tracks into playing on 13.3.1, the infamous 28 second "-" symbol returned. The issue is with 13.3.1 (or a prior release).

My setup is iTunes streaming from PC to multiple Airplay compatible devices with an Orbi mesh network. Music is a mix of my own library as well as Apple Music. The music type playing has no bearing on the issue. I've recreated the issue both ways. The only common factor is 13.3.1.

It's also important to note that I can play from my phone to the speaker with no issue. The problem here is that the speaker "takes over" the playlist. A bit after starting to play, I can no longer skip or control from iTunes on my phone. I have to open the Home app to control the playback. This is with hand off to Homepod disabled. This is one issue I've not wasted time troubleshooting but thought I'd mention it.

I spent a LONNNNG time with Apple support and not only did they have me recreate the issue for them on Homepod they had me experience the same issue on airplay through AppleTV. They acknowledge there's an issue and they are aware. Let's hope for a resolution soon. Best advice is to contact them and go through the motions so they can gather data on this issue.

So no dice on turning off the homepod features, however I have found a pattern in the packet capture correlated with the failure. I no longer think this is an issue with the homepod, but a problem solely with iTunes.

Every 30 seconds, iTunes sends a TCP message to homepod port 7000 with an OPTIONS message that provides cseq number, user agent, instance ID, and a remote ID. Between these messages, the homepod will send a TCP Keep-Alive to my PC from port 7000 every 6 seconds. After 4 of these, iTunes sends the options message.

When the issue occurs, that 30 second interval TCP options message does not get sent. That's why the other poster was encountering the issue at the 28 second mark each time. That is the refresh interval for this options message.

We can see in the packet capture, the TCP fin message comes as soon as the 30 second interval passes without the options message being sent from iTunes:

This leads me to believe that it might be possible to spoof this options message to the homepod using a 3rd party tool, therefore keeping the stream alive even when itunes fails to send the options message itself. That will be my next task.

Bumbeen/Bryan debugged the issue and fixed the issue respectively. Huge respect to both of them. Again, shame on Apple.

Please refer to the post from Bryan above.

Download this utility so that Airplay stack continually maintains connection between iTunes and HP.

http://www.loseyourmind.com/volume-adjuster-for-itunes.aspx

What's up ya'll. So I just opened a case with Apple on this issue. Been bugging me for months and I'm just now starting to troubleshoot in earnest. When I perform a wireshark capture on my PC while airplaying from itunes to homepod, I notice I Get a TCP FIN from port 7000 on the homepod back to my PC right as the audio stops. iTunes continues to send the UDP audio stream to the homepod for some time however, and is then flooded with ICMP destination port unreachable messages. Eventually the homepod will send a TCP Reset from port 7000 and that's when itunes stops.

Since this does not happen with my iphone airplaying to the homepod(and I mean local airplay from my phone to homepod, not handoff). I am getting the impression this is a bug in the airplay server on the homepod and it is only exposed due to the way airplay is implemented in itunes. This is backed up by the success some people have had with using airfoil instead of itunes. Perhaps if we could compare the control data from airfoil vs itunes we can identify the discrepancy and isolate the specific cause of the failure.

Regardless of all that, I want it to work with itunes, so my next step is going to be disabling everything possible on the homepod to see if that helps.

Hey guys, so I don't seem to have the skills to spoof the options packets. But I did find a workaround that suffices for homepod if you've a spare PC(or a virtual machine) to run iTunes, might work for apple tv but haven't tried that.

Basically all you need to do is change the volume by 1% every 25 seconds. This sends traffic on that port 7000 therefore keeping the TCP stream alive regardless of whether or not iTunes sends the OPTIONS message like it's supposed to.

I scripted this task with autohotkey on a spare laptop. I feel like there's a better way to do it so you could run it on your main PC in the background but I'm not an expert on autohotkey.

Loop {

WinActivate, iTunes

MouseClickDrag, Left, 306, 20, 307, 20

Sleep, 25000

WinActivate, iTunes

MouseClickDrag, Left, 307, 20, 306, 20

Sleep, 25000

}

All this does is move the volume slider in itunes by one pixel to the right, waits 25 seconds, then moves the slider to the left by one pixel, repeat ad infinitum.

Now my packet capture looks like this:

This never gives it the chance to close that TCP connection on port 7000, and 1% volume change isn't enough for me to even hear.

Doug, I am guessing that the older versions of the homepod or apple TV software had a longer timeout than 30 seconds and that's why the issue isn't present there. So much for whole Apple ecosystem "all our stuff works well together!" idea. Though I guess iTunes on windows has always been the black sheep of Apple software.

I'm supposed to hear back from apple today on my case, but I have zero faith that they'll fix it any time soon.... It's been broken for months so it's clearly not a high priority for them.

So for the record, Apple support recommends 5G. Reboot was done multiple times. Homepod was updated to 13.4 the day it was released and Apple support contacted me to see if anything change with functionality...it did not.

The issue I have has nothing to do with playing from mobile devices. It's when I attempt to airplay from my PC via the iTunes application. It's a confirmed issue with Apple and the issue occurs with both Homepod and AppleTV.

It probably doesn't matter which service you disable. 2.4GHz has the greater reliable range, 5GHz the greater speed. Having both active seems to leave HomePod the option to hunt for the best service between the two and fail in its primary function of playing music.

tt2

I think I found the issue. I have received my new HomePod

from Best Buy today. It came with 11.2.5 (I tested without updating to 13.4).

So far, I have been able to play music for over 45 minutes without it

disconnecting and showing the infamous "-". In addition, I downgraded

my Apple TV4 to 10.2.2. I have been able to Airplay music with no disconnects

on HomePod and Apple TV. My conclusion is there is an issue with the IOS

software and not iTunes. Hopefully, the next update resolves the issue. If

enough of us complain we have a better chance of them fixing the issue. Apple

HELP!

After struggling with this maddening issue for months on end, your suggestion solved the problem for me. I turned off the 5GHz band on the router and all other devices on LAN, rebooted everything, and the Airplay2 connectivity between my router, HomePods, and Sonos speakers improved 95%. I'll take it.

Well, it's complicated. Multiple systems. Not iTunes under Windows, but iTunes on two old legacy iMacs and Music on one newer iMac and two MacBooks Pro. Air Play functions far more reliably on all of those systems, once I ditched the 5GHz band on everything. My 2.4 GHz band is very crowded, but even so everything is working better.

NOT AT ALL HELPFUL - EVER!

What's next "Ctrl-Alt_del? Don't you think that if a person is intelligent enough to sign in, 2 factor authenticate twice or three times, accept Apple's two EULAs ..... they JUST might have done that?