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@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
