使用xbmc/kodi作爲dlna render設備時，連接到某些wifi熱點/路由器上，不能被dlna control找到發現的問題——原因是WIFI模組深度優化後，從省電模式喚醒時，會丟失組播包

測試環境及條件如下：
1)wifi熱點爲我們工作環境用的普通路由器時，xbmc安裝在開發板上，作爲dlna render設備時,是可以被dlna control(爲手機上的音樂apk,如魅族MX4 Pro自帶的音樂apk)發現的。

但是，當wifi熱點是採用tplink的TL-TR861 5200L無線路由器MIFI（ http://www.tp-link.com.cn/product_290.html [ ^]）或者用手機做wifi熱點時，則常常找不到xbmc/kodi,無法推送音樂給開發板上的xbmc。採用上述熱點，基本是非常偶爾的情況下能找到xbmc.

在開發板上用tcpdump抓包發現，開發板似乎只能抓到板子自身發出去的網絡包，偶爾抓到兩個其它設備發出的udp廣播包 (MBNS)，大部分其它設備發出的網絡包抓不到。

所以，dlna推送時找不到開發板上的xbmc，應該是就沒有收到手機音樂apk發出的查找dlna render的udp組播包

如果先啓動手機上的推送音樂的apk,然後再啓動開發板上的xbmc，此時是手機端是能夠發現開發板的xbmc並推送音樂給它的。原因是手機端能收到xbmc啓動上線時的notify組播包，然後主動詢問連接了開發板。

2)將xbmc作爲dlna render,裝在其它平板上，同樣鏈接到tplink的TL-TR861 5200L無線路由器MIFI，與我們的開發板進行對比測試。

與其它平板對比發現，在其它平板上的xbmc是能夠被手機端發現的，而我們的開發板不能——主要表現爲組播的丟包率比較高。

3)將xbmc與其它的dlna render的apk(採用了DLNA互動播放器)進行對比：xbmc與dlna互動播放器均安裝到我們的開發板上，且wifi連接到tplink的TL-TR861 5200L無線路由器MIFI:

對比可見：使用DLNA互動播放器(基於cling開發的dlna render apk),它在開發板子上能輕易被手機找到，原因是xbmc的dlna庫是採用platinum庫，DLNA互動播放器採用cling庫。DLNA互動播放器會以一定週期不停發送ssdp的notify組播包，通知同一網絡中其它設備自己的存在，這樣，即使沒 有收到推送方的Search包，依舊可以通過notify包來讓自己被推送方發現。
而xbmc沒有週期性發送ssdp包。我們也不能採用上述方法，因爲如果採用，則開發板將不能進入休眠，會比較耗電。同時，這樣的方法也會給網絡環境帶來不影響，產生大量的垃圾包。

後與wifi模組廠商聯繫，發現最終原因：

我們開發板採用的wifi模組是經過深度優化的，連接到tplink的TL-TR861 5200L無線路由器MIFI上時，與連接到工作環境下的普通路由器相比，測試時，前者——TL-TR861 5200L無線路由器比較閒，只有推送設備的手機與開發板連接其上，開發板的wifi模組會進入到一個省電模式，當wifi模組被喚醒，退出省電模式時，會丟失幾十到幾百個組播包(單播不丟失)，所以導致開發板收不到推送設備上線的組播search包。而後者——工作環境下的普通路由器因爲有很多設備連接其上，比較繁忙，開發板的wifi不能進入到一個省電模式，一直工作在正常模式下，所以不會丟失組播包

至於xbmc作爲dlna render被裝到其它平板上，能被推送設備發現，是因爲其它平板的wifi模組沒有做此深度優化。