[vdr] Re: vdr[3330]: ERROR: can't record MPEG1! - possible cause

[Usenet-372111@zocki.toppoint.de (Rainer Zocholl)]

Usenet-372111@zocki.toppoint.de(Rainer Zocholl)  24.09.01 23:21

Once upon a time Rainer Zocholl shaped the electrons to say...

>werner@suse.de(Dr. Werner Fink)  24.09.01 12:02

>Once upon a time Dr. Werner Fink shaped the electrons to say...

>>On Sat, Sep 22, 2001 at 08:59:00PM +0200, Rainer Zocholl wrote:
>>>
>>>>which kernel version?
>>>
>>> Linux version 2.4.9 (root@msi) (gcc version 2.95.2 20000220 (Debian
>>> 2.2)
>>>
>>> (kernel from kernel.org)

>>IMHO plain 2.4.9 isn't very stable.

>Because 2.4.10 was released yesterday i tried:

>It is much better :-)
>Not Oops (in the last 3 minutes :-))

But that mail was too early.


>"MPEG1" only occurs when i record on both card
>simultanious, but only one per (some) minute(s).

>But there are still "glitches" in audio,
>the image contains sometimes artefacts
>Video and audio runs/are outof sync (i assume
>because frames are dropped/broken.)
>A/V resync can't be forced with "pause", "rewind" is required.



>kernel 2.4.10
>dvb-20000923
>vdr-0.96
>lirc-0.6.4pre3
>i2c-2.6.1
>libc-2.1.3
>gcc 2.95.2


>(with kernel 2.4.9 simultanious recordings leads to
>Kernel panic oops 002 , but not all ways)

>recording with the primary card alone always works very
>artefact free

>recording with kernel 2.4.9 on a PIII 1000MHz 133FSB
>fails on the second card (broken frames, half frames)

>recording with a 700MHz 66MHz FSB  works relatively good,
>but artefacts are there too.



Now i can add:
Recording with the 2.4.10 from the second card also fails with the
same "oops" as with 2.4.9.


Is there any DVB-developer reading this thread?

What is his suggestings to go further?
Annoyingly the Ooops-Screen seems not the be dumped
into varlog.


It not my PC alone i know mean while.
There are other who have artefacts in audsio and video too.
There seems to be a Clock limit arround AMD-500MHz/64KB
upto which the recording -seems- to be OK.
>From 700MHz on the artefacts are more, ending at
Intel-1000MHz with unusable records.


Is there a place in the driver where some hardware registered 
are polled to get a special bit toggled (0->1->0) (that would be
a very ugly hardware, not to handle by software in a realtime 
environement)?
Or where such a "peak" should be generated and is done by software
"delay"?

The problem becomes obvious only on the second card.
The first card is much better.


Rainer---<=====>                         Vertraulich
             //  
           //                              
         <=====>--------------ocholl, Kiel, Germany ------------