I agree. To me it sounds like an mDNS issue, if the multicast handling of the router (especially over wi-fi) is a bit shaky it may result in the behaviour you experience.

Solution? Probably a firmware upgrade from Sagemcom (or Broadcom, who is responsible for the chipset of your cable modem). Maybe you should contact your ISP (or whoever it was who supplied the 3890). Apart from this, it's a really good unit.

I use a 3890v3 (same SoC, slightly different wi-fi chipsets) and I have similar experiences, btw.

henrik wrote:

To me it sounds like an mDNS issue, if the multicast handling of the router (especially over wi-fi) is a bit shaky it may result in the behaviour you experience.

mbolo01 wrote:

If these packets are lost then the devices appear unreachable for the respective service, while the router/switch will show them stil connected to the network.

If you have a computer on your network, I would start using the ping command against each device to see if you have packet loss, abnormal latency variation

This is very likely some sort of a network issue with other wifi router. In my case, I am using Google Wifi Mesh and both Core and A9 show up every time with my HomePods and other gear. My assumption of why your Apple TV is showing up but not the A9 is perhaps because your Apple TV is wired.  Also, if my A9 does not show up for AirPlay on my iPad or iPhone, I can recycle my iPad or iPhone rather than the A9 or Core to see it. The current firmware on the A9 is rock solid in my experience, but it needs a stable wifi connection.

He means "restart" of course.  "Recycle" is what one does with one's old, bricked, Sonos CR100's!:-)

Restarting the iDevice is easier than the A9, because it's in your lap rather than across the room.  But it still doesn't say where the bug lies.  Does waiting -- for minutes -- at the selection pop-up on the iDevice finally show the A9, accomplishing the same thing as restarting the iDevice?  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.)

trackbeo wrote:

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.)

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...

trackbeo wrote:

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.

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.

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.