[Interest] Strange socket problem. QTcpSocket. Windows/Linux

[Guido Seifert]

> Do we know that Samsung didn't do that?  (except that if they had, it would probably work well ;-)

Actually it is a Linux that is running in Samsung TVs. Maybe it is not the firmware, but the hardware?
 
> Anyway, if you are already researching with wireshark, you can find some uPnP software that does work with that TV, and see what is different.  If you're lucky it might be a matter of a packet size limit or something like that.

I did. But compared only the human readable part. This is definitely correct. Apart from that, my UPnP code works with Samsung E and F and XBMC and bubbleUPnP on Android. Only the Samsung D series has this problem. Did not test C series, yet. So where ever this problem is located, it is on a lower level to which I don't have access. It is a normal tcp connection via QTcpSocket and QTcpSocket does not have that many parameters, which I can tweak. And the few there are, are already tried in all possible permutations. No effect at all. Even if I knew what the difference between a socket initiated by Linux and one by Windows I probably would not be able to fix anything.

It looks like the code seems to work a couple of times, but to receive UPnP events, the eventing must be resubscribed in a regular
interval. 5 min fix on Samsung TVs.  After 3 - 10 resubscriptions the socket is dead. It takes data, seems to be in perfect 
working order, but the Samsung does not react. Same when I send play and stop UPnP commands. Works several times, then I get socket 
error -1. I can hammer the port, e.g. send the stop command a few dozen times. After a while it starts working again for a few commands, then it fails again. While the necessary interval for eventing resubscriptions is fix, I am free to choose the rate in which I send the
play or stop commands. The failure trigger definitely does not depend on the time between two commands. It seems to happen randomly.

Guido