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

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

Rainer Zocholl wrote:
> 
> 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)

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 5
model           : 8
model name      : AMD-K6(tm) 3D processor
stepping        : 12
cpu MHz         : 451.014
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr
bogomips        : 901.12

> 
> What gcc?
> 
> Here:
> msi:~/video# gcc --version
> 2.95.2

kls@video:/home/kls/vdr/VDR > 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?

That code has been taken from example code that comes with the driver.
I didn't "invent" it, so I'm afraid I can't say too much about how
it actually works.

> One question is:
> What is the difference between recording with the first
> or the second card?
> 
> One thread/two threads?

Should make no difference. There are always two threads for a recording.

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
_______________________________________________________________