[PATCH] random vdr-sxfe xvdr+tcp:// restart failures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

 I finally debugged this and found the read() looking for the initial
"DATA\r\n" was sometimes gobbling up too much, i.e. the start of
the first ts packet when the server was sending it fast enough which
caused the demuxer to be out of sync and interpreting parts of the
ts packet as header with a way too big data size, and that caused
vdr-sxfe to bail out.

 This patch fixed it for me:

--- a/xine_input_vdr.c
+++ b/xine_input_vdr.c
@@ -5639,7 +5662,7 @@ static int connect_tcp_data_stream(vdr_i
     LOGERR("Data stream write error (TCP)");
   } else if( XIO_READY != io_select_rd(fd_data)) {
     LOGERR("Data stream poll failed (TCP)");
-  } else if((n=read(fd_data, tmpbuf, sizeof(tmpbuf))) <= 0) {
+  } else if((n=read(fd_data, tmpbuf, sizeof("DATA\r\n") - 1)) <= 0) {
     LOGERR("Data stream read failed (TCP)");
   } else if(n<6 || strncmp(tmpbuf, "DATA\r\n", 6)) {
     tmpbuf[n] = 0;

 (Tho one may want to replace the other occurences of "6" with
"sizeof("DATA\r\n") - 1" there too to make clear where they come
from.)

 HTH, :)
	Juergen

_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux