Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Klaus.Schmidinger@cadsoft.de(Klaus Schmidinger)  20.09.01 18:12

Once upon a time Klaus Schmidinger shaped the electrons to say...

>Ansgar Jonietz wrote:
>>
>>
>> I think it's not only a NOVA-related problem:
>> As i posted some time ago I have the same problem -- but with two
>> full Hauppauge 2.1 cards.
>> I didn't solve the problem yet, i will try using VDR0.95 with a
>> current driver instead of VDR0.85.
>>
>> The errors occurs only on recordings, not with live watching.

Jepp.

>> Sometimes there are also messages "unknown picture type":
>>
>> Aug 22 11:51:57 ophelia vdr[32132]: ERROR: can't record MPEG1!
>> Aug 22 11:51:57 ophelia vdr[32132]: ERROR: unknown picture type '6'
>> Aug 22 11:51:57 ophelia vdr[32132]: ERROR: can't record MPEG1!
>> Aug 22 11:55:51 ophelia vdr[32132]: ERROR: can't record MPEG1!
>>
>> Ansgar.

>Just for the record: I have three Siemens DVB-S cards and do a lot of
>recordings on various channels, but don't get any of these error
>messages. I'm using the latest (well, almost, haven't installed last
>night's changes yet) CVS driver with VDR 0.95.

What CPU do you have?

Here: 

msi:~/video/VDR# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 10
cpu MHz         : 996.697
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat pse36 mmx fxsr sse
bogomips        : 1985.74

RAM 133MHz SDRAM (Maybe CL2, not sure, will note next boot) 


What gcc?

Here:
msi:~/video# gcc --version
2.95.2


void cTS2PES::instant_repack(const uint8_t *Buf, int Count)

Still can't explain how that calling 
parameter "Count" can become zero.
That seems to be a "read only" variable.
I assume that it should tell the number of bytes in "Buf"

Maybe i'm fooled by printf:

esyslog(LOG_INFO, 
"ERROR: can't record MPEG1! -  Flag1 %x c:%d Count: %d found:%d Zero:%d Rekurx:%d"
                                    ,flag1
                                          ,c
                                                    ,count
                                                             ,found
                                                                     ,iZeroCount
                                                                              ,iReCurs);





I too wonder why the "slightest" code changes 
changes the behavior so much.

I added the volume patch to vdr.c:
vdr.c did remake and restart 
vdr reboots the card and berboots the ard
with that funny i2c-adapter error numbers.

removed the patch and remake only
killall vdr runvdr
/etc/init.d/vdrstart start
vdr now runs.


In this case it maybe be:
As long as the cpu is very busy "Count" is never set to zero.
There are always already data available when CPU asks for.
On a faster PC VDR with only two cards is not so busy remuxing etc.
so the chance that no data is available may be given?



One question is:
What is the difference between recording with the first 
or the second card?

One thread/two threads?



Home | Main Index | Thread Index