[mythtv] [PATCH] EOF readStringList caused by 802.11b?

[Colin Cross]

Here's how I have my system set up:
1 master backend running FC2
1 frontend running on same FC2 computer
2 frontends running on FC2 behind an 802.11g bridge
1 frontend running on FC2 behind on an 802.11b USB adapter
1 frontend running on Debian behind another 802.11g bridge

Everything worked fine using the atrpms.net packages for 0.15.  When I 
upgraded to the atrpms.net 0.16 packages, all the FC2 frontends worked 
except the one on the 802.11b adapter (the Debian one hasn't been 
updated yet).

On the 802.11b adapter frontend, I can watch LiveTV, see the program 
guide, look at the backend info, etc.  The only thing I can't do is see 
the list of recorded programs or upcoming recordings.  It always says 
"Sorry, no recordings available" and the following messages show up in 
the logs:
2004-09-24 20:33:02 All Programs
2004-09-24 20:33:04 Connecting to backend server: 192.168.0.2:6543 (try
1 of 10)2004-09-24 20:33:04 Using protocol version 13
length mismatch between programinfo
Waiting for data: 7232 168854
EOF readStringList 144792

The error means the frontend is giving up on the readStringList after 
reading 144792 of 168854 bytes.  Looking at the code 
(libs/libmyth/util.cpp), it appears that it will fail if it takes more 
than 100 reads to get all the data.  I guess the latency and throughput 
limitations of the 802.11b USB adapter cause it to break the data up 
into more than 100 reads.  If I change it to fail on 100 reads of zero 
bytes instead of failing on 100 reads, my broken frontend works fine. 
I've attached a 1-line patch that does just this, although I didn't mess 
with the very similar QSocket version of ReadStringList for the backend, 
since my problem was only with the frontend.

This still seems like the wrong way of handling the network transaction. 
  Wouldn't it be better to rely on a timeout instead of the number of 
reads that didn't finish?  The size string reading uses a timeout to 
wait for 8 bytes.  Also, the counter that counts to 100 is called 
zerocnt, suggesting that the code was originally meant to count reads of 
zero bytes instead of just reads.  Does anyone know if/why it was 
changed to the current logic?

Finally, there are small usleeps sprinkled throughout the network code, 
many of them in a loop that calls a blocking function anyways.  If these 
are just to force the thread to yield, wouldn't it be better to call 
usleep(0), or leave them out completely on a blocking loop?  On a faster 
network, the usleep(50)'s could dominate the throughput of the network code.

If others agree I'll submit a more thorough patch.
-------------- next part --------------
Index: libs/libmyth/util.cpp
===================================================================
RCS file: /var/lib/mythcvs/mythtv/libs/libmyth/util.cpp,v
retrieving revision 1.36
diff -u -r1.36 util.cpp
--- libs/libmyth/util.cpp       7 Aug 2004 13:08:33 -0000       1.36
+++ libs/libmyth/util.cpp       26 Sep 2004 05:59:46 -0000
@@ -180,7 +180,7 @@
         // cerr << "  read: " << temp << endl; //DEBUG
         read += temp;
         size -= temp;
-        if (size > 0)
+        if (temp == 0)
         {
             if (++zerocnt >= 100)
             {