1)wifi热点为我们工作环境用的普通路由器时,xbmc安装在开发板上,作为dlna render设备时,是可以被dlna control(为手机上的音乐apk,如魅族MX4 Pro自带的音乐apk)发现的。
所以,dlna推送时找不到开发板上的xbmc,应该是就没有收到手机音乐apk发出的查找dlna render的udp组播包
如果先启动手机上的推送音乐的apk,然后再启动开发板上的xbmc,此时是手机端是能够发现开发板的xbmc并推送音乐给它的。原因是手机端能收到xbmc启动上线时的notify组播包,然后主动询问连接了开发板。
与其它平板对比发现,在其它平板上的xbmc是能够被手机端发现的,而我们的开发板不能——主要表现为组播的丢包率比较高。
3)将xbmc与其它的dlna render的apk(采用了DLNA互动播放器)进行对比:xbmc与dlna互动播放器均安装到我们的开发板上,且wifi连接到tplink的TL-TR861 5200L无线路由器MIFI:
而xbmc没有周期性发送ssdp包。我们也不能采用上述方法,因为如果采用,则开发板将不能进入休眠,会比较耗电。同时,这样的方法也会给网络环境带来不影响,产生大量的垃圾包。
后与wifi模组厂商联系,发现最终原因:
我们开发板采用的wifi模组是经过深度优化的,连接到tplink的TL-TR861 5200L无线路由器MIFI上时,与连接到工作环境下的普通路由器相比,测试时,前者——TL-TR861 5200L无线路由器比较闲,只有推送设备的手机与开发板连接其上,开发板的wifi模组会进入到一个省电模式,当wifi模组被唤醒,退出省电模式时,会丢失几十到几百个组播包(单播不丢失),所以导致开发板收不到推送设备上线的组播search包。而后者——工作环境下的普通路由器因为有很多设备连接其上,比较繁忙,开发板的wifi不能进入到一个省电模式,一直工作在正常模式下,所以不会丢失组播包
至于xbmc作为dlna render被装到其它平板上,能被推送设备发现,是因为其它平板的wifi模组没有做此深度优化。