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@xxxxxx
