[linux-dvb] Re: No more data after EBUFFEROVERFLOW - Solved!

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Ralph Metzler wrote:
> 
> Klaus Schmidinger writes:
>  > There have been several reports that VDR stops recording after
>  > the driver reports an EBUFFEROVERFLOW (which is listed in the log
>  > file as "Unknown error 769" since EBUFFEROVERFLOW is only defined
>  > inside the driver's code).
>  >
>  > Taking a close look at DVB/driver/dmxdev.c I saw that the 'buffer.error'
>  > is initialized to '0' in DmxDevBufferInit(), and later set to various
>  > error codes - but NEVER reset to '0'. Apparently this causes the driver
>  > to no longer deliver (useful) data.
>  >
>  > Am I missing something?
>  > Shouldn't buffer.error be reset at some point?
>  > Or must the application (VDR) do something special after receiving
>  > EBUFFEROVERFLOW to reset that error condition?
> 
> If you look more closely (like a search for "error" in dmxdev), you
> will see that the error is cleared in DmxDevBufferRead()
> after being read.

Ooops, sorry - I only searched for buffer.error and buffer->error.

> Most probably the next overflow error already occured before you
> called read() again.

I found now what's causing the broken recordings after a EBUFFEROVERFLOW.
Apparently there were incomplete TS packets in VDR's ringbuffer which
caused the cRemux to get out of sync. Actually a check for the TS_SYNC_BYTE
has always been missing in VDR.

Here's a patch to remux.c which makes sure it syncs on a TS packet after
a buffer overflow (or any othe reason that might cause a loss of sync):

--- remux.c     2001/06/24 16:37:23     1.5
+++ remux.c     2001/08/19 11:52:05
@@ -489,6 +489,8 @@
   resultCount = resultDelivered = 0;
 }
 
+#define TS_SYNC_BYTE 0x47
+
 const uchar *cRemux::Process(const uchar *Data, int &Count, int &Result, uchar *PictureType)
 {
   uchar dummyPictureType;
@@ -511,11 +513,26 @@
      resultDelivered = 0;
      }
 
+  int used = 0;
+
+  // Make sure we are looking at a TS packet:
+
+  while (Count > TS_SIZE) {
+        if (Data[0] == TS_SYNC_BYTE && Data[TS_SIZE] == TS_SYNC_BYTE)
+           break;
+        Data++;
+        Count--;
+        used++;
+        }
+  if (used)
+     esyslog(LOG_ERR, "ERROR: skipped %d byte to sync on TS packet", used);
+
   // Convert incoming TS data into multiplexed PES:
 
-  int used = 0;
   for (int i = 0; i < Count; i += TS_SIZE) {
       if (Count - i < TS_SIZE)
+         break;
+      if (Data[i] != TS_SYNC_BYTE)
          break;
       int pid = GetPid(Data + i + 1);
       if (Data[i + 3] & 0x10) { // got payload

With this fix bytes will be skipped until two consecutive TS_SYNC_BYTE
at a distance of TS_SIZE appear. A buffer overflow will still cause
a disturbance in the recording (since data actually is lost), but the
recording will be continued after "good" data is received again.

All this is, of course, not the driver's fault. The application has to
make sure it is in sync with the incoming data.

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.