測試環境及條件如下：
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模組沒有做此深度優化。