Now, if the controlling app (Glider or 8Player) is listening to multicast advertisment messages, then Poly should be heard as a kind of workaround to doing Search responses properly. As 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 do it
From the spec for DLNA page 26: “Choosing an appropriate duration for advertisements is a balance between minimizing network traffic and maximizing freshness of device status. Relatively short durations close to the minimum of 1800 seconds will ensure that control points have current device status at the expense of additional network traffic;”
Issue #2 with this is that it turns out that these broadcasts are also in fact broken on Poly - they actually stop after a short while:
Initially Poly is multicasting 400 length series messages including 407 - Media server service and 419 - Content Directory
Now I notice that these are the Poly advertisements after about 30minutes:
There are no more advertisements for:
407 - Media server service
419 - Content Directory
So any app will not see that there is a renderer (player) or any content. I captured network traffic for a further 5 minutes and saw zero of those advertisements.
Presumably those services have crashed in addition to not implementing IGMP Join requests to get multicast messages.
So, the net-net is Poly not discoverable by 8player or Glider and this is a particular issue when linked to the other problem of not joining a multicast group using IGMP.