[vdr] CAM-Start: Delay?

[Reinhard Nissl]

Hi,

Wolfgang Goeller wrote:

>> @Wolfgang:
>> Would you please run VDR with Option   -l 3   to get dsyslog() 
>> messages logged and supply a reasonable excerpt of /var/log/messages?
>>
>> Do you get this messages from the transfer thread's instance of cRemux 
>> or from the recording thread's instance? If VDR is not running in NPTL 
>> mode, then you can "simply" tell this by looking at the process id 
>> which is part of every syslogged message.
> 
> I still get the messages when I start recording, but since the 
> buffer-increasing they go away after the startup
> If it helps I could use vdr without increased buffers to get more
> errors. But what I can see are errors in the transfer and the
> record thread.

When running with default buffers, do you get the same number of errors 
for both cRemux instances (i. e. while a recording is active) as in the 
sample you sent recently?

What's your machine's CPU load when a recording kicks in?

Could disk activity cause dropping of some TS packets?

Locate cTS2PES::ts_to_pes() in remux.c and activate the following line, 
which is currently a comment:

         //dsyslog("TS continuity error (%d)", ccCounter);

Do you now get such messages in front of c*Repacker messages?

Could you check your syslog setup to make sure that such debug messages 
go into the same file as esyslog() messages (c*Repacker uses them)? A 
simple test would be to look for the following messages in your 
/var/log/messages:

    dsyslog("setting watchdog timer to %d seconds", WatchdogTimeout);
    dsyslog("max. latency time %d seconds", MaxLatencyTime);
    dsyslog("assuming manual start of VDR");
    dsyslog("next timer event at %s", *TimeToString(Next));

Some of them are always generated when starting VDR.

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de