Sign in   |  Join   |  Help

Airplay problems

rated by 0 users
Not Answered This post has 0 verified answers | 28 Replies | 1 Follower

MWJ
Not Ranked
11 Posts
OFFLINE
Bronze Member
MWJ posted on Sat, Apr 4 2020 6:50 AM

Hi all,

 

I have some very weird issues with airplay playback on my speakers. I currently have an A9 MkII, an M5 and an M3 connected to my wifi.

Sometimes I can stream via airplay to the speakers, sometimes not. In all instances, if I power cycle the speakers, they show up on airplay after reboot.

Usually the M5 and A9 show up in Spotify under Spotify connect which always works, but the same speaker might not show up on airplay, even though it is available for Spotify connect.

When I log in to my router, I can see that all the speakers are connected to the network (as the speakers' diodes indicate), but to no avail. Whether they are available on airplay is completely random, but most often not.

Obviously this is an issue, since airplay is the only way I can use multi-room streaming. 

I have contacted B&O support, and they offered several fixes, but nothing helps.

(And by the way: my Apple TV ALWAYS shows up in the airplay menu....)

Anybody with a solution ?

All Replies

mbolo01
Top 50 Contributor
Louannec - France
2,005 Posts
ONLINE
Bronze Member
trackbeo:

If not, then that's a bug in the iDevice's mDNS "gathering" algorithm/cache. (Because the iDevice is *supposed* to rebroadcast the query and rebuild the list periodically.)

Or mDNS queries/responses are lost somewhere in the path

BS Moment, BS Core, BG 4002, BC 4500, BS1, BL18, BL19, BL8000 + RCV1, A6, M5, M3, A1, P6 (tks Botty), H5, TR1

trackbeo
Top 150 Contributor
626 Posts
OFFLINE
Bronze Member

If mDNS queries/responses are lost somewhere along the path, how is restarting the iDevice any different than waiting for a re-broadcast?  If it is, that must be because of some bug in whatever router is maintaining said path, where the new request for a DHCP lease from the restarting iDevice clears some logjam?  Like resetting all the ARP cache IP-MAC entries?  Hmm... But in that case, restarting *any* device on the same network might do the trick... 

By the way, the idea above about ping-ing devices would not necessarily work, because the OP has an AppleTV on his network, and the AppleTV will act as a Sleep Proxy (if the router isn't already doing so).  (According to Stuart Cheshire, "To reduce unnecessary wakeups, the Sleep Proxy will wake a sleeping machine only when the proxy sees an incoming IP UDP packet or incoming IP TCP connection request for a Bonjour-advertised service on the sleeping machine. In particular this means that “pinging” a sleeping machine WILL NOT wake it, since “ping” is not one of the Bonjour-advertised services on the sleeping machine.")

Upshot: here are some experiments the OP can try to see if the A9 will stay visible as an Airplay speaker:  Restart the iDevice.  Leave off the AppleTV.  Restart the AppleTV.  Restart the Wi-Fi access point/router.  If the A9 is the culprit, none of these things should work.  If it is responding as it should, one of them ought to "make" it visible again?  Worth a try at least...

matador43
Top 75 Contributor
1,359 Posts
OFFLINE
Bronze Member

trackbeo:
If mDNS queries/responses are lost somewhere along the path, how is restarting the iDevice any different than waiting for a re-broadcast?  If it is, that must be because of some bug in whatever router is maintaining said path, where the new request for a DHCP lease from the restarting iDevice clears some logjam?  Like resetting all the ARP cache IP-MAC entries?  Hmm... But in that case, restarting *any* device on the same network might do the trick... 

Dont know if it's related but when a speaker disappear he stay on the speaker list on the airplay menu. I just can hear it has not started.
If i try to deselect it to reselect again in order to start it, then it disappear from the list of available speakers. One way to make it re-appear is t start iTunes from my phone ans scan for available Airplay speakers. Then the phone finds it and at the same time it appears again on the airplay list from the computer.

trackbeo
Top 150 Contributor
626 Posts
OFFLINE
Bronze Member

Yeah, OK, let me prefix the following by saying that I am absolutely *not* an expert:

That smells to me *exactly* like some bug with Sleep Proxy on a network and a device that is not aware of such behavior!  The iDevice says "tell me about yourselves, all you Airplay renderers", and, everybody responds, except that without waking any sleeping devices, the Sleep Proxy server responds for some of them.  How?  It has substituted its own MAC address for theirs and the router sends messages to it.  So the Sleep Proxy says, "Yes, here I am: DeviceName(etc.)" for every device which has slept but it thinks does not need to awaken, because hey, it's "only" supplying names/DNS services, right?  But then the iDevice tries to set up the stream to one of them before sending data, whereupon the Sleep Proxy gets its first packet that it knows must be handled by the device. So it tells the router to switch back the MAC address (how? I dunno, maybe TTL=0?) and then sends the special wake packet, and then also passes along the packet it knows the device must handle itself.  How long does the wake take?  Does the Sleep Proxy know how long to wait before passing that first packet?  Does the device have a packet buffer?  If it's UDP, does the packet just go off and get ignored by a waking device?  If it's TCP, how long does the sending device wait before deciding to retransmit (or give up)?  All unknown to me, though someone at B&O must have written code for this case.

That correlates to how a speaker device might be seen, but then takes longer than usual to start playing, and sometimes... just doesn't!  Now, I do not *know* that an A9 can sleep, or that yours is sleeping.  And I do not know if Bonjour Sleep Proxy is responsible.  But what you just said sure looks suspicious.  

If you are not using Apple Airport's for wireless or routers (which also have Sleep Proxy built in), I would at least *try* turning off the AppleTV and restart all the rest of your network, then use it like normal, and wait to see if the A9 works as well as all your other devices.  This may be a total red herring.  But at least it's easy to test.

matador43
Top 75 Contributor
1,359 Posts
OFFLINE
Bronze Member

Thank you Trackbeo,

I'm not the original poster and my problems are related to non B&O speakers.
B&O stuff are hooked to Airport bases and behaving well.

Anyway, all you wrote make sens to me as it seems to be some sort of technical description to what I usually experience.
Now i have to figure how to turn this into a fix.

All the best.

MWJ
Not Ranked
11 Posts
OFFLINE
Bronze Member
MWJ replied on Mon, Apr 6 2020 8:37 PM

Hi Trackbeo

I will give it a shot. However, I had the problems before the apple tv was connected. 
By the way: I am using a Ethernet via power grid from the router to the Apple TV. All the B&O speakers are connected wireless. 
Also, if the problem was the sleep-command, would Spotify connect then work so consistently?

 

thanks again for your replies.  

trackbeo
Top 150 Contributor
626 Posts
OFFLINE
Bronze Member

Reminder: soak my opinions in a brine bath...  What I *suspect* is: Because of the way Spotify Connect works -- streaming direct from their server, piercing your router's NAT & firewall, requested direct by the playback speaker -- and not streaming thru your iDevice running the Spotify App -- that the setup & teardown protocol is so complicated that the playback speaker was already completely awake.  Why?  Because it had to tell Spotify's server, over the Internet, where to reach it.  That still doesn't explain why the very beginning of that setup process doesn't fail too -- but it is, at least, different, and probably why it works.

(If you didn't really mean "Spotify Connect" but you meant "the 'More Devices' menu item which shows all my Airplay speakers in Spotify's 'Available Devices' menu", then I *really*, really don't know, because that should work thru the same mechanism as any other Airplay output from that same iDevice.  In my current home setup, Spotify Connect only shows up in the "Available Devices" menu as routing to my Sonos , and all the other devices are off the Airplay menu item.  But I no longer have the A6 and don't remember if it did Spotify Connect, or not.)

MWJ
Not Ranked
11 Posts
OFFLINE
Bronze Member
MWJ replied on Tue, Apr 7 2020 3:13 PM

Hi. 
they appear (the A9 and M5 - M3 does not support Spotify connect) under ‘devices available’ directly  If I then select ‘AirPlay’ the speakers often times don’t show up.  

MWJ
Not Ranked
11 Posts
OFFLINE
Bronze Member
MWJ replied on Wed, Apr 8 2020 7:20 AM

Hi Mbolo01,

Unfortunately this is inconclusive as well, I think. (I am no network expert).

When I ping the speakers, I get inconsistent results. Right now, I can ping the M3 and M5 with good results. The A9 is unreachable. 

Only the M3 is available for airplay. The A9 and M5 are available for Spotify connect. 

And now a weird thing: The A9 (and my iPhone) are now listed as connected to ethernet port 3 on my router even though they obviously are connected via wifi. This happens often - devices connected via wifi appear as connected through the ethernet ports. Dont know if this is of any relevance.

I connected to the A9 and M5 separately through Spotify connect. This seems to have woken up the M5, which is now available for airplay. The A9 is still not available for airplay, and cannot be ping'ed

 

After a power cycle of the A9, it is reconnected to the network (same IP address). It responds to ping and can be connected to via airplay.

 

I am about to give up here.....

MWJ
Not Ranked
11 Posts
OFFLINE
Bronze Member
MWJ replied on Wed, Apr 8 2020 7:33 AM

Hi Mbolo01,

I tried to ping all the units. Unfortunately this is inconclusive as well, I think. (I am no network expert).

When I ping the speakers, I get inconsistent results. Right now, I can ping the M3 and M5 with good results. The A9 is unreachable. 

Only the M3 is available for airplay. The A9 and M5 are available for Spotify connect. 

And now a weird thing: The A9 (and my iPhone) are now listed as connected to ethernet port 3 on my router even though they obviously are connected via wifi. This happens often - devices connected via wifi appear as connected through the ethernet ports. Dont know if this is of any relevance.

I connected to the A9 and M5 separately through Spotify connect. This seems to have woken up the M5, which is now available for airplay. The A9 is still not available for airplay, and cannot be ping'ed

 

After a power cycle of the A9, it is reconnected to the network (same IP address). It responds to ping and can be connected to via airplay.

 

I am about to give up here.....

mbolo01
Top 50 Contributor
Louannec - France
2,005 Posts
ONLINE
Bronze Member

MWJ:
I am about to give up here.....

Don't give up!

I don't know your router, but it is really suspicious. Your local area network seems very simple according to your description: an ISP provider router / switch / WiFi with a handful of network nodes connected wireless, you should not have such issues. Ping test resulting in high latency variation, packet lost and host unreachable is a sign of a very serious network problem.

Do you have other issues such as Internet browsing, watching Youtube video or listening to Internet music from your phone? Have you contacted your ISP? Do you have a mean to share your router configuration? even by PM, hiding any private information.

Rel to Wifi devices appearing connected to an Eth port, it could be by design in this type of router, while being very strange ... it is like if you had an external Wifi access point, connected to the relevant Eth port, showing all wireless devices connected to this external Wifi access point. I wonder what would be shown if all Eth ports were busy with real wired network devices?

In another post, where similar issues have been reported, I advised to install the Discovery free app (there is an IOS version). With this app you can see all products and all services advertising themselves on the network via the mDNS protocol, including Airplay, Google Cast and Spotify Connect. Maybe you should give a try and see if same inconsistencies are seen, i.e. by clicking on a given service such as _airplay._tcp. (Airplay receivers), you'll see all the products that have announced themselves so normally all B&O speakers. This will not solve the issue, but may may confirm what you are already seeing through the B&O app or IOS, i.e that service information such Airplay is not propagated well which would double confirm a network issue, so a router issue.

If you could borrow/purchase a Wifi Access Point, plug it to one of the ISP router Eth port, disable the ISP router Wifi and see if you have improvement, this would definitively confirm an issue with the ISP router.

BS Moment, BS Core, BG 4002, BC 4500, BS1, BL18, BL19, BL8000 + RCV1, A6, M5, M3, A1, P6 (tks Botty), H5, TR1

MWJ
Not Ranked
11 Posts
OFFLINE
Bronze Member
MWJ replied on Fri, Apr 10 2020 1:14 PM

Thanks again

I downloaded the app and will check for inconsistencies. 
I have another router, which I will try to set up later to see if it is more consistent  

troyh
Not Ranked
8 Posts
OFFLINE
Bronze Member
troyh replied on Wed, Feb 24 2021 6:10 PM

Did you ever figure out a solution? 

I'm having the same problem and it's definitely a multicast DNS issue over WiFi. It seems to me that this is a bug in the B&O software or a problem with the WiFi hardware in the B&O devices. I've talked to B&O customer support but they don't yet have an answer.

My setup:

I have several B&O products, some are wired and some use WiFi. The wired ones work reliably with AirPlay but the WiFi ones don't. If I wire one of the WiFi ones it then works reliably. I also have Apple TVs (some wired, some WiFi) and Apple HomePods (WiFi only) and they have no problems. 

The B&O devices that disappear from AirPlay all work on the network fine: I can ping them and they can stream TuneIn radio stations without any interruptions and if I AirPlay to them they don't ever drop the music. So they are networked and the network seems to be fine. The network is a simple Ubiquiti UniFi network with a UniFi switch and several UniFi access points (that are all wired) scattered around the house. 

Because they stay networked reliably, it seems to me that the B&O devices just stop answering multicast DNS queries for a little while and then start answering them again. 

I've been watching all my AirPlay devices on my network using dns-sd to browse AirPlay devices which runs continuously and says when a device is available and when it isn't. What you don't see in the output is all the AirPlay devices that advertise themselves and never change state.

Here's the output of dns-sd -B _airplay._tcp (on a Mac)... the first column is the time of day, "Add" means the device is advertising itself and "Rmv" ("Remove") means it's not, "4" and "6" mean IPv4 and IPv6, that's why there's 2 of each of them. You can see that 2 of the devices (a Level and a Balance, both on WiFi) come and go every few minutes:

8:58:15.712  Rmv        1   4 local.               _airplay._tcp.       Lounge Balance
 8:58:15.712  Rmv        0   6 local.               _airplay._tcp.       Lounge Balance
 8:58:27.608  Rmv        1   4 local.               _airplay._tcp.       Beosound Level
 8:58:27.608  Rmv        0   6 local.               _airplay._tcp.       Beosound Level
 8:58:39.463  Add        2   4 local.               _airplay._tcp.       Lounge Balance
 8:58:39.476  Add        2   4 local.               _airplay._tcp.       Beosound Level
 8:58:39.525  Add        2   6 local.               _airplay._tcp.       Lounge Balance
 8:58:39.531  Add        2   6 local.               _airplay._tcp.       Beosound Level
 9:07:36.865  Rmv        1   4 local.               _airplay._tcp.       Lounge Balance
 9:07:36.865  Rmv        1   4 local.               _airplay._tcp.       Beosound Level
 9:07:36.865  Rmv        1   6 local.               _airplay._tcp.       Lounge Balance
 9:07:36.865  Rmv        0   6 local.               _airplay._tcp.       Beosound Level
 9:09:39.665  Add        3   4 local.               _airplay._tcp.       Lounge Balance
 9:09:39.665  Add        2   4 local.               _airplay._tcp.       Beosound Level
 9:09:39.690  Add        2   6 local.               _airplay._tcp.       Lounge Balance
 9:09:39.690  Add        2   6 local.               _airplay._tcp.       Beosound Level
 9:10:22.760  Rmv        1   4 local.               _airplay._tcp.       Lounge Balance
 9:10:22.760  Rmv        1   4 local.               _airplay._tcp.       Beosound Level
 9:10:22.760  Rmv        1   6 local.               _airplay._tcp.       Lounge Balance
 9:10:22.760  Rmv        0   6 local.               _airplay._tcp.       Beosound Level
 9:10:26.714  Add        3   4 local.               _airplay._tcp.       Lounge Balance
 9:10:26.714  Add        2   6 local.               _airplay._tcp.       Lounge Balance
 9:10:26.734  Add        2   4 local.               _airplay._tcp.       Beosound Level
 9:10:26.921  Add        2   6 local.               _airplay._tcp.       Beosound Level
 9:23:45.648  Rmv        1   4 local.               _airplay._tcp.       Lounge Balance
 9:23:45.648  Rmv        0   6 local.               _airplay._tcp.       Lounge Balance
 9:29:46.248  Rmv        0   4 local.               _airplay._tcp.       Beosound Level
 9:29:47.355  Rmv        0   6 local.               _airplay._tcp.       Beosound Level
 9:41:55.044  Add        2   4 local.               _airplay._tcp.       Lounge Balance
 9:41:55.135  Add        2   6 local.               _airplay._tcp.       Lounge Balance
 9:44:04.414  Add        2   4 local.               _airplay._tcp.       Beosound Level
 9:44:04.587  Add        2   6 local.               _airplay._tcp.       Beosound Level
 9:46:12.977  Rmv        1   4 local.               _airplay._tcp.       Beosound Level
 9:46:12.977  Rmv        0   4 local.               _airplay._tcp.       Lounge Balance
 9:46:17.885  Rmv        1   6 local.               _airplay._tcp.       Beosound Level
 9:46:17.885  Rmv        0   6 local.               _airplay._tcp.       Lounge Balance
 9:46:27.441  Add        2   4 local.               _airplay._tcp.       Beosound Level
 9:46:27.479  Add        2   4 local.               _airplay._tcp.       Lounge Balance
 9:46:27.626  Add        3   6 local.               _airplay._tcp.       Beosound Level
 9:46:27.626  Add        2   6 local.               _airplay._tcp.       Lounge Balance

I have 2 other Balances, one is currently wired and the other is on WiFi but they are fine right now, but later today the WiFi one will also disappear from AirPlay and come back. I also have 2 Beosound Stages (both WiFi) that seem to be more reliable but they also come and go at times. Again, all the wired B&O devices and all the Apple TV and HomePods whether they're wired or WiFi work reliably.

 

 

MWJ
Not Ranked
11 Posts
OFFLINE
Bronze Member
MWJ replied on Thu, Feb 25 2021 10:16 AM

Hi

 

Yes I did. 
the problem was caused by my 5ghz network. Apparently it produces interference which gives problems with airplay

Initially I had the 5ghz network set up with a different ssid and password than the 2.4ghz, but that still caused problems. 

once I deactivated the 5ghz network, everything worked fine and has worked perfectly for long now.

hope this works for you.  

Page 2 of 2 (29 items) < Previous 1 2 | RSS
Beoworld Security Certificate

SSL