The platinum library cannot search the debug process records of some projection devices

        Using open source libraries to improve engineering efficiency is basically a necessary skill for every programmer , But sometimes open source and free code , Most of the time, the author just wants to show off his skills 、 Built for hobbies and other reasons , The pit may be abandoned at any time , This is the time when bug You can only make up for it by yourself , This is what happened to me this time —— Open source projects are used in the project Platinum As the basic component of screen projection , But it always happens that the equipment cannot be found , Finally, only by reading the agreement , Infer the location of the problem , Then use a similar dichotomy , Keep narrowing down the code that may cause problems , Finally found bug The root cause of . Here's how I fixed this bug Process record of .

One 、 Introduction ：

      We used Platinum Ku as DLNA For screen SDK Basic components of , However, it is often found that it can not find some set-top boxes and other devices that can be used for screen projection , But other APP The screen projection function of can receive normally . This means that there may be some problems in the library , And the author hasn't updated it for a long time , So I can only do it myself debug.

Two 、 To solve the process ：

        At first, it took some time to get familiar with Platinum Library code , There's a certain amount of complexity , It also makes me suddenly lose confidence in repairing this problem , Think about trying other libraries first ？ But look at open source DLNA There are a lot of libraries , Different word of mouth , Compatibility is not necessarily good ,Platinum The reputation of the library is relatively good . If you want to try the effect one by one , Uncertainty may take more time than actually finding the root cause of the problem , So I gave up this road .

        First step , Since there is something wrong with the search process , So first understand DLNA Protocol and search related parts ：

       DLNA Based on projection search SSDP agreement （Simple Service Discovery Protocol, Simple service discovery protocol ）, use UDP Transmit packets . The specific logic is summarized as follows ：

    

        First , Projection end to multicast address 239.255.255.250:190 Send multicast message , The information is as follows ：

       

       （Platinum The default in the library is upnp:rootdevice, You can refer to the method PLT_CtrlPoint Constructors ）      

      then , After receiving this message at the screen end , Will respond to the following ：

     

 

  Of these two messages ,LOCATION All attributes have one IP Address , This is the device description file of the projected end , Describe the manufacturer of this device 、 Device definition 、 Equipment display URL、 List of services 、 equipment UUID Etc ,SDK According to these equipment information, it can be recorded in the table , Wait for the user to select the device and operate according to the information .

        The second step , Control variable method , Grab the bag SSDP Agreement information , Make sure it's the projected end , There is still a problem at the projection end ：

        The previous hard work of getting familiar with and understanding the code is not in vain ,Platinum Library PLT_InputDatagramStream::Read The method is used to receive the data packet sent by the projected end , Insert a log It's just convenient to confirm whether the projected end can send... Normally SSDP package . give the result as follows ：

equipment 1, Music casting screen TV End ：

equipment 2, Tmall box ：

equipment 3, Glory box

      You can find Platinum The library can receive 100% of the response information of all devices in the LAN , Then the possibility of problems at the projected end can be ruled out , All that's left is to continue tracking, received SSDP What happened to the data post-processing process .

        The third step , Track data flow , Observe carefully ：

        Keep watching Platinum The processing of response data by the library , Look at the processing logic of the code , When it is found that some equipment cannot be found occasionally , This method will make some UUID Your device cannot proceed to the next step ：

among ,NPT_ContainerFind The implementation is as follows ：

        In fact, it is a typical way to look for one from the table item Whether there is any code . But why did you find uuid stay m_PendingInspections After this container, it will not continue to execute the subsequent process ？ Why is the subsequent process not implemented , The list doesn't show the device ？

        So continue to observe PLT_CtrlPointGetDescriptionTask Code for , combination Platinum The basic logic of the library , It can be found that it is a thread pool task , It is used to obtain and the device in the background description And analyze task, Eventually it will send the data it receives , Call back here ：

       

Now let's see PLT_CtrlPoint::ProcessGetDescriptionResponse Method ：

        The logic is to parse the device description , Delete m_PendingInspections Corresponding in container uuid, And create a device object , Add to m_RootDevices In the container , At this time, the upper layer can see the device through the list .

        So the author designed m_PendingInspections Your intention is obvious , I just don't want to repeat the same UUID Create multiple background task, In order to save resources , So maybe something's wrong here ？

        The answer is yes , By adding log, The discovery of its mechanism will lead to the receipt of three different UUID when , Only created 3 individual task, And this 3 individual task The response waiting in the queue , There are two devices from the same ！（ Speculation is to ensure that the projected end can receive its own response , So there is indeed a set-top box that will respond several times in a short time ）, There is no more task Go to the device that sends the response later , In the end, it's just 2 Devices added to m_RootDevices In the container , And because no corresponding number of task Deal with the equipment behind , There is one UUID Your device will never have a corresponding task To go from m_PendingInspections Delete your own... From the container UUID, Cause even if it's done again m-search The transmission of signals , Receive another response UUID when , because m_PendingInspections The... Still exists in the container UUID, Still won't continue to create task Handle the UUID, But directly ignore , In this way, it is no longer possible to find the... Before creating the next process UUID I've got a new device . That's what it's about bug Root cause of ！

        

resolvent ：

      Delete the corresponding de duplication logic , Each response corresponds to a background PLT_CtrlPointGetDescriptionTask, To ensure that the equipment information is updated normally , And can receive responses from all devices . The solution has been proved effective by self-test ：

Finally, all devices can be seen no matter how many times they search ：

summary ：

1、 Even if the open source project itself is relatively large , But most of the time, the problem to be solved is only caused by a small subset of the code , Finding relevant process parts can speed up understanding and debug Speed .

2、 A lot of code based on some protocol or some theory , To quickly understand how its specific functions work , We must first understand its protocol and theory , At least understand the part you need .

3、 You can first think of the code as a black box , Try different inputs , Observe the law of output , Follow the clue , Constantly deconstruct the logic related to the code , Understand why the output does not match the target .

Last , To the author issue：