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.