![transmit for windows 10 transmit for windows 10](https://panic.com/transmit/images/share-twitter-image.png)
I don't see any reason why the msgno incrementing would stop when a packet is not sent out. So there should be no other side effects visible others than that a packet is missing on the output. Before #974 the app simply ignores the fact that Windows has rejected to send out a packet. If the msgno is not incremented, I assume that the app does not even try to send out those packets. No msgno is assigned to them and they are not sent out via SRT. However in my above example there are six UDP packets received by the app which are simply ignored. I haven't done another recording to verify it. I might agree that #974 could fix that one missing packet. I see no reason for increasing the timeout. However, definitely there is no reason for Windows to need more than 50 ms to send that small packet while the computer's CPU use is at 3% and network use at less than 1%. Let's assume that because the app has just sent UMSG_ACKACK, Windows needs some time to send the other UDP packet which the app delivered at the same time. Bitrate is around 6 Mbit/s, so shouldn't be a problem for Windows to handle it without any waiting on sending operations. In my above example there is only one SRT packet which has not been sent out.
#Transmit for windows 10 windows 10#
Running on Windows 10 20H2 physical machine. The SRT receiver indicates one resent packet (msgno 2316500) and no dropped packets, although six UDP packets are missing after the SRT path.Īs Wireshark can see those UDP packets, I assume that they are also received by the application srt-live-transmit-win64-noencryption and get lost somehow inside the application. Then it continues working again for a few minutes without dropping packets. The last UDP packet with the size of 794 translates to msgno 2316501 and is transmitted normally via SRT. The next six received UDP packets are simply ignored.
![transmit for windows 10 transmit for windows 10](https://www.thewindowsclub.com/wp-content/uploads/2017/12/Network-Adapter-Troubleshooter.png)
It is only transmitted later after receiving UMSG_LOSSREPORT for that packet from the receiver. The second UDP packet wit the size of 1358 translates to msgno 2316500 and is not transmitted via SRT. The first UDP packet with the size of 1358 translates to msgno 2316499 and is transmitted normally via SRT. This is what I can see in Wireshark on the places where packets are dropped: So there are UDP packets that arrive fine to srt-live-transmit-win64-noencryption, but are not present after the SRT path without any notification of packet loss neither in the SRT sender nor in the SRT receiver. The statistics shows no missing/dropped packets. Wireshark will show the received UDP packets but some of them are simply not present in the SRT output. When I use srt-live-transmit-win64-noencryption (SRT Library version: 1.4.2) to receive UDP packets and send them out via SRT, not all UDP packets are sent out.