[linux-dvb] Re: dvb-kernel TS continuity errors

[segarral@free.fr]

Hi,

I have maybe this kind of problem with a WinTV Nova-S budget card:

When I'm recording a TS, some payloads (188 bytes) are forgotten.

A consequence is, for example, when I'm listenning to the 'Radio FG'
with mpg123, I can read the error message:
   Illegal Audio-MPEG-Header

(RadioFG: 12207MHz-V-27500-3/4- APID: 243)

I have the same problem with some other transponders (not so many).

I check this: When I edit the recording file and have a look to the counter
which is in the header of payload of 188 byes, I can see some jumps.

Is this the same kind of problem? Am I the only one in this case?
please, if you have a WinTV Nova-S, could you tell me if you can
listen to 'Radio-FG' without any 'Illegal Audio-MPEG-Header' ?

PS: I added some lines to dvbtraffic to see when I loss some payloads
(188bytes). If someone is interesting...

Thinks.


Selon Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>:

> Klaus Schmidinger wrote:
> >
> > I'm currently testing VDR under kernel 2.6 with the dvb-kernel
> > driver (version from linuxtv.org CVS as of 2004-09-10).
> >
> > When I run 5 parallel recordings on the same transponder
> > (RTL, RTL 2, Super RTL, VOX and RTL Shop) it works just fine on a full
> > featured DVB card, while I get TS continuity errors when I
> > do the same thing on a WinTV NOVA-S budget card.
> >
> > What makes this so strange is that normally it is said that
> > a _budget_ card can deliver the full TS, while a full featured
> > card is limited in what it can deliver. In this scenario it would
> > appear that the FF card works better than a budget card.
> >
> > Could it be that there is a bug in the budget card driver
> > that causes problems with multiple recordings from the same
> > transponder (which means high data transfer rate)?
> >
> > Note that with two recordings on the budget card (RTL and RTL 2)
> > I don't get these problems. The more recordings I run on the same
> > budget card, the more TS continuity errors I get. On the FF card
> > with 5 recordings I don't get a single continuity error. Needless
> > to say that the recordings where the continuity errors happened are
> > broken (video and audio artefacts), while those made with the FF card
> > are perfectly fine.
> >
> > Also, during all these tests there were no buffer overflows in VDR,
> > and also none in the driver (at least none that were reported by the
> > read() call).
> >
> > One observation is that with 5 recordings the FF card typically returns
> > some 30KB in one read(), while the budget card delivers around 4KB per
> > read(). So with the budget card there are apparently a lot more read()
> > calls. Don't know whether this constitues a problem, though.
> >
> > Any ideas what could be causing this?
> >
> > Klaus
>
> I just realized that the dvb-kernel driver apparently numbers the
> devices differently than the old DVB driver did. With the old driver
> I had the following device sequence
>
>   0  FF card
>   1  budget card
>   2  FF card
>
> while with dvb-kernel I have
>
>   0 FF card
>   1 FF card
>   2 budget card
>
> I became aware of this when I was wondering why my CAM was detected
> at the "second" card, while it is physically attached to the "third"
> card (as seen by the old driver).
>
> So what I wrote above is apparently wrong - the budget card does deliver
> a flawless data stream, even with 5 parallel recordings. It's the FF card
> that has the problems.
>
> Klaus
>
>
>


--