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