10-29-2021 04:46 AM
I got an R610 with 188.8.131.52.243 which does not give me any problems in general, except for one thing: airplay
I have tried almost everything, incl. for the AP to have 0% connections on 2.4GHz to force connections on 5GHz.
I stream from my iPad Pro which always connect with 802.11ac which is streaming to an Raspberry Pi 4B+ running RoPieeeXL (Airplay).
My problem is; when the Raspberry connects with 802.11n my iPad will loose the connection to the RPI within 20-30 seconds after I start streaming, when I then use the Troubleshooting (Unleashed) which can force the RPI to connect with 802.11ac the airplay connection will work for hours.
What I do understand is why does the connection get cut when the RPI connects with 802.11n and not with 802.11ac ?
Any recommended settings I should try out?
This is driving me crazy, as this is how I listen to radio ....
10-29-2021 06:47 AM
I have to add to the above, that there are dropouts even with the RPI is connected with 802.11ac. Only difference is that it "only" happens every 5-15 minutes, and with ac the connection is not lost.
10-29-2021 07:03 AM
You have the worst possible combination -- open source client, closed source Apple server, and very sensitive service. You can just hope that you are not the first making this weird mix...
10-29-2021 07:16 AM
@eizens_putnins you're possibly right. I used to have Unifi nanoHD's - and never had a problem with this specific thing - many other problems though.
For me it looks as if the Ruckus resets something every so many seconds, which causes the connection to be broken. But what it is, that is the big question.
10-29-2021 07:50 AM
As much as I understand, currently Airplay 2 uses multicast, so you probably need to look in multicast configuration. Airplay 1 was unicast, I think, and had bigger buffer, so it was much more stable in bad conditions.
AP usually resets something connections when requests are incorrect -- which easy can be a case with both Apple (which has own opinion about all standarts) and RPI (which may not follow any standards). It could play better with UBNT, as they have very basic software, without any additional services or checks, and no interest to comply closely with any standard too, which in some cases may be a positive thing, actually.
But most probably in fact in current situation UBNT would have even more problems, as generally Ubiquity AP are not too good.
But thing may be as simple as unfortunately chosen WiFi channel and interference -- try to change a channel, make spectral analyses and look for interference sources. Look into logs -- what exactly happens, when connection is dropped? Run sniffer on RPI to see what packets are lost or whatever else happens...