Devices on a network each have IP addresses and can send messages to each other where they explicitly include on the envelope (packet) the destination IP address.
When they want to search for devices, they can send a “broadcast” message and all devices listen for those.
In order to cut down on these broadcast messages a hybrid message was invented decades ago called a multicast message. These “multicast” messages are sent to a specific IP address like 220.127.116.11 and all those listening for this address hear it. This is an example of the “Hey, are there any DLNA folks out there?” messages.
Normally a “dumb” network sends copies of every single message or packet to every single device and relies on the devices to ignore stuff thats not addressed to them. As you can imagine this can cause a huge amount of unnecessary messages being sent to devices who don't need them.
Smarter networks learn which devices are where either physically or on which WiFi channels (For example they can also be on 2.4GHz or 5GHz) and only send packets to the places or frequencies where there is actually a device who needs that packet.
Smarter networks are as a result less “congested” and operate better. This certainly is the case when you have multiple wifi transmitters (or Access Points) on your network.
It turns out if Poly is the Wifi device (Poly is in hotspot mode) or the Phone is the hotspot then, well, they act like dumb networks and send everything everywhere.
Multicast packets are a special case. On a smart network essentially no multicast flows between devices unless they have specifically asked to “join a multicast group” using something called Internet Group Management Protocol.
Searching is in section 1.3.2 (This is what DLNA apps will do to find Poly) Responses Poly should give are listen in section 1.3.3
A core part of DLNA devices finding each other is to do an M-SEARCH or Multicast Search. This means that all DLNA devices should be subscribing to hear the multicast messages… or they never hear the requests for a search.
Below is a trace of my network where I powered up Poly and my iPhone. Notice how the iPhone, when I launch Glider, asks to join 18.104.22.168 and 22.214.171.124. Now, the smart network knows that whenever it sees those addresses on packets, they need to be forwarded to the access point and out to the iPhone who asked to receive them on whatever WiFi channel its on…
However… poly is not on this list. It never asks to join 126.96.36.199 and so Glider and 8Player can ask to find sources as much as they want, and send out Multicast search messages…. but the network itself is smart and will never send the multicast M-SEARCH requests on to the Poly because it never asks to receive multicast traffic in the first place. Good network, bad Poly.
(In the screenshot, 10.0.1.1 is the router, 10.0.1.111 is another iPad.)
What Poly DOES do is simply to send out Multicast advertisements on this Multicast group telling anyone willing to listen that it hosts several DLNA services, for example that its a player, as well as a source for music: (Side note: Notice the 400 series entries below? Another bug causes them to actually stop after a while)
And once again, if you are on the same network and this stuff isn't filtered by default, you'd see it. SO folks with simple networks or “dumb” networks will work fine.
But again, on a smart network, when both clients are in the same access point, even though you'd think they'd hear each other because their just sending Wifi messages and everyone hears them, they don't…
The iPhone is on 5GHz and the Poly is 2.4… so the Access point, even if there is only one, is receiving the multicast on 5GHz and has to forward it back out on 2.4… and because its smart and doesn't want to flood the network (Why would it send to the 2.4 if nobody is listening) it blocks it.
See how the Poly is on channel 1 and the iPhone is on channel 44 - they're not tuned to the same station, so they never hear each other, and rely on the Access point to relay info, which is does for the traffic from Poly TO iPhone bit not the other way because Poly didn't ask to hear it:
The solution is for Poly to also send IGMP group join messages when it connects to networks. By default under Linux this is off and needs to be turned on even if by a simple shell command on Poly:
Now, all this said, if the controlling app (Glider or 8Player) IS asking to hear those multicast advertisment messages, then the broadcasts that happen by Poly should be heard as a kind of workaround, so long as its advertising all the necessary DLNA services. (This was the “fix” attempted in version 1.0.6) In fact Poly is actually sending those advertisement packets every second or so…
Issue #1 with this is that this is a lazy/slack/spammy way to doit and…
Just implement IGMP joins and do this right. It'll solve the above 3 issues by avoiding the need for them in the first place.
For those with a simpler network, their devices ignore multicast and send them as broadcasts instead, avoiding all of this and Poly works… but its a hack at best.