Hello When I restart vdr due to a failure in the descrambling sometimes vdr does initialize the CAM too late. During the initalizing vdr starts recording but the CAM is not ready. Channel not available.... Would it be possible to give a longer delay before vdr starts recording from a encrypted channel? Would be nice allthough there are other workarounds.
Regards Wolfgang
Wolfgang Goeller wrote:
Hello When I restart vdr due to a failure in the descrambling sometimes vdr does initialize the CAM too late. During the initalizing vdr starts recording but the CAM is not ready. Channel not available.... Would it be possible to give a longer delay before vdr starts recording from a encrypted channel? Would be nice allthough there are other workarounds.
Which version of VDR are you using?
2005-08-21: Version 1.3.30
... - Now waiting at startup until all DVB devices are ready. This includes having all CAMs initialized and ready to decrypt, so that no more "channel not available" happens if VDR is started with the current channel being an encrypted one, or a timer on such a channel hits right after starting VDR.
Klaus
Klaus Schmidinger wrote:
Wolfgang Goeller wrote:
... Would it be possible to give a longer delay before vdr starts recording from a encrypted channel? Would be nice allthough there are other workarounds.
Which version of VDR are you using?
My fault - partly. I downgraded to 1.3.29 because with the later versions I with VIACCESS-encyrpted channels errors like: cVideoRepacker: skipped 720 bytes while syncing on next picture (someone reported the same with Premiere)
After your replay I gave 1.3.34 another try - but I did increase in transfer.c the TRANSFERBUFSIZE to 4 MB.
That solved both problems. No more cVideoRepacker - Errors and the benefit of better initializing the CAM. Might be others who have the cVideoRepacker - error might give this modification a try to see whether it's just luck or really helps
Thanks & regards Wolfgang
Wolfgang Goeller wrote:
Klaus Schmidinger wrote:
Wolfgang Goeller wrote:
... Would it be possible to give a longer delay before vdr starts recording from a encrypted channel? Would be nice allthough there are other workarounds.
Which version of VDR are you using?
My fault - partly. I downgraded to 1.3.29 because with the later versions I with VIACCESS-encyrpted channels errors like: cVideoRepacker: skipped 720 bytes while syncing on next picture (someone reported the same with Premiere)
After your replay I gave 1.3.34 another try - but I did increase in transfer.c the TRANSFERBUFSIZE to 4 MB.
That solved both problems. No more cVideoRepacker - Errors and the benefit of better initializing the CAM. Might be others who have the cVideoRepacker - error might give this modification a try to see whether it's just luck or really helps
Have you made both changes at the same time?
What about "plain vanilla" VDR 1.3.34 (w/o the change to TRANSFERBUFSIZE)?
I just want to know whether this latter change is really necessary.
Klaus
Hello Klaus
After lots of recordings I can say: In the first Minute of the recording (happens only with Swiss encrypted channels ((Viacess)) ) I get even now some cVideoRepacker errors on one of my machines On the other no error since I encreased the TRANSFERBUFSIZE. My feeling: It is sort of curing symptoms but better than nothing.
With plain vanilla vdr 1.3.34 I get this errors and thus lots of audio-drop-outs. I don't get it from the encrypted Austrian channels. So it might depend on the way this module is handled.
Sorry - but I can't tell you more.
regards Wolfgang
After your replay I gave 1.3.34 another try - but I did increase in transfer.c the TRANSFERBUFSIZE to 4 MB.
That solved both problems. No more cVideoRepacker - Errors and the benefit of better initializing the CAM. Might be others who have the cVideoRepacker - error might give this modification a try to see whether it's just luck or really helps
Have you made both changes at the same time?
What about "plain vanilla" VDR 1.3.34 (w/o the change to TRANSFERBUFSIZE)?
I just want to know whether this latter change is really necessary.
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Wolfgang Goeller wrote:
Hello Klaus
After lots of recordings I can say: In the first Minute of the recording (happens only with Swiss encrypted channels ((Viacess)) ) I get even now some cVideoRepacker errors on one of my machines On the other no error since I encreased the TRANSFERBUFSIZE. My feeling: It is sort of curing symptoms but better than nothing.
With plain vanilla vdr 1.3.34 I get this errors and thus lots of audio-drop-outs. I don't get it from the encrypted Austrian channels. So it might depend on the way this module is handled.
Sorry - but I can't tell you more.
regards Wolfgang
@Reinhard Nissl: do you have any idea why an increased TRANSFERBUFSIZE would reduce error messages from cVideoRepacker?
Klaus
After your replay I gave 1.3.34 another try - but I did increase in transfer.c the TRANSFERBUFSIZE to 4 MB.
That solved both problems. No more cVideoRepacker - Errors and the benefit of better initializing the CAM. Might be others who have the cVideoRepacker - error might give this modification a try to see whether it's just luck or really helps
Have you made both changes at the same time?
What about "plain vanilla" VDR 1.3.34 (w/o the change to TRANSFERBUFSIZE)?
I just want to know whether this latter change is really necessary.
Klaus
Hi,
Klaus Schmidinger wrote:
Wolfgang Goeller wrote:
After lots of recordings I can say: In the first Minute of the recording (happens only with Swiss encrypted channels ((Viacess)) ) I get even now some cVideoRepacker errors on one of my machines On the other no error since I encreased the TRANSFERBUFSIZE. My feeling: It is sort of curing symptoms but better than nothing.
With plain vanilla vdr 1.3.34 I get this errors and thus lots of audio-drop-outs. I don't get it from the encrypted Austrian channels. So it might depend on the way this module is handled.
Sorry - but I can't tell you more.
@Reinhard Nissl: do you have any idea why an increased TRANSFERBUFSIZE would reduce error messages from cVideoRepacker?
I can only think of transfer buffer overflows which cause calling cRemux->Clear(). After that, the c*Repacker instances resync and may tell some error messages.
@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.
Bye.
Hallo Reinhard
@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.
regards Wolfgang
vdr[19794]: transfer thread started (pid=19794, tid=180229) vdr[19781]: switching device 1 to channel 42 vdr[19781]: timer 6 (42 2210-2300 'Testaufnahme') start vdr[19781]: Title: 'Meteo' Subtitle: '' vdr[19781]: record /video/Testaufnahme/2005-11-01.22.10.50.90.rec vdr[19781]: recording to /video/Testaufnahme/2005-11-01.22.10.50.90.rec/002.vdr' vdr[19795]: file writer thread started (pid=19795, tid=196614) vdr[19796]: recording thread started (pid=19796, tid=213001) vdr[19796]: cAudioRepacker(0xC1): skipped 306 bytes while syncing on next audio frame vdr[19794]: cAudioRepacker(0xC1): skipped 306 bytes while syncing on next audio frame vdr[19796]: cAudioRepacker(0xC1): skipped 1468 bytes while syncing on next audio frame vdr[19796]: cAudioRepacker(0xC1): skipped 1468 bytes while syncing on next audio frame vdr[19796]: cAudioRepacker(0xC1): skipped 210 bytes while syncing on next audio frame vdr[19794]: cAudioRepacker(0xC1): skipped 1468 bytes while syncing on next audio frame vdr[19794]: cAudioRepacker(0xC1): skipped 1468 bytes while syncing on next audio frame vdr[19794]: cAudioRepacker(0xC1): skipped 210 bytes while syncing on next audio frame vdr[19796]: cAudioRepacker(0xC1): skipped 4 bytes to sync on next audio frame vdr[19794]: cAudioRepacker(0xC1): skipped 4 bytes to sync on next audio frame
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.
Hello Reinhard
@Wolfgang: Would you please run VDR with Option -l 3 to get dsyslog() messages logged and supply a reasonable excerpt of /var/log/messages?
Just to be complete: After the recording thi cAudioRepacker messages continue as long as the channel remains on Swiss - as you can see from the messages that start with the end of the recording.
Since my recording computer is remote I can't tell what is on the screen - But just a guess: On my local computer I get from the CAM (VIACCESS) if tuned to SFDRS the message "No Right" ... press OK to continue. Could the cAudioRepacker-error be related to that?
ASAP I'll look in your last message.
regards Wolfgang
Nov 1 23:00:00 gorgias vdr[19796]: recording thread ended (pid=19796, tid=213001) Nov 1 23:00:00 gorgias vdr[19795]: file writer thread ended (pid=19795, tid=196614) Nov 1 23:00:00 gorgias vdr[19781]: cTS2PES got 0 TS errors, 1 TS continuity errors Nov 1 23:00:00 gorgias last message repeated 2 times Nov 1 23:00:00 gorgias vdr[19781]: buffer stats: 67492 (0%) used Nov 1 23:00:00 gorgias vdr[19781]: timer 6 (42 2210-2300 'Testaufnahme') stop Nov 1 23:00:01 gorgias vdr[19917]: video directory scanner thread started (pid=19917, tid=229382) Nov 1 23:00:01 gorgias vdr[19917]: video directory scanner thread ended (pid=19917, tid=229382) Nov 1 23:00:38 gorgias vdr[19794]: cAudioRepacker(0xC0): skipped 1294 bytes to sync on next audio frame Nov 1 23:00:38 gorgias vdr[19794]: cAudioRepacker(0xC0): skipped 1626 bytes while syncing on next audio frame Nov 1 23:00:38 gorgias vdr[19794]: cAudioRepacker(0xC0): skipped 114 bytes while syncing on next audio frame Nov 1 23:01:00 gorgias vdr[19781]: deleting timer 6 (42 2210-2300 'Testaufnahme') Nov 1 23:04:30 gorgias vdr[19794]: cAudioRepacker(0xC0): skipped 475 bytes to sync on next audio frame Nov 1 23:04:30 gorgias vdr[19794]: cAudioRepacker(0xC0): skipped 475 bytes to sync on next audio frame Nov 1 23:04:53 gorgias vdr[19786]: ERROR: can't set filter (pid=160, tid=02, mask=FF): Device or resource busy Nov 1 23:05:33 gorgias vdr[19794]: cAudioRepacker(0xC0): skipped 702 bytes while syncing on next audio frame Nov 1 23:08:21 gorgias vdr[19786]: channel 13 (ORF2) event 22:40 'Zwischen Liebe und Leidenschaft' status 4 Nov 1 23:08:22 gorgias vdr[19786]: channel 12 (ORF1) event 21:57 'Collateral Damage - Zeit der Vergeltung' status 4 Nov 1 23:08:42 gorgias vdr[19794]: cAudioRepacker(0xC0): skipped 4 bytes to sync on next audio frame Nov 1 23:09:03 gorgias vdr[19794]: cAudioRepacker(0xC0): skipped 1148 bytes while syncing on next audio frame
Hello Reinhard
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?
No I got definitely more - don't know why. My Machine is AMD Athlon(tm) XP 2000+ based with 750 MB OS is SuSE 9.0 The only plugin for vdr is remote-plugin. My recorder-card is a Hauppauge Nexus Recording is done to a software Raid 0 - array of two disks. The system resides on a separate disk. There is no other disk-activity than just that of the recording. On the machine there is as long as recording is done next to no activity (neither disk nor anything else). My CPU is according to top between 80 and 90% idle during records Typically: 15-19% system 0-0.3% user Tasks: 77 total, 6 running, 67 sleeping, 5 stopped
I changed remux.c according to your proposal and started a new recording - swiss channel already tuned in from the previous recording. It started without any cAudioRepacker-error but after 7 Minutes I got the following messages: (( BTW: after the recording ended, the messages showed up again)) (Note the CAM - message!)
Nov 2 00:07:06 gorgias vdr[20670]: cAudioRepacker(0xC0): skipped 572 bytes while syncing on next audio frame Nov 2 00:07:06 gorgias vdr[20670]: cAudioRepacker(0xC1): skipped 1468 bytes while syncing on next audio frame Nov 2 00:07:06 gorgias vdr[20670]: TS continuity error (8) Nov 2 00:07:06 gorgias vdr[20670]: TS continuity error (2) Nov 2 00:07:06 gorgias vdr[20670]: cAudioRepacker(0xC1): skipped 1468 bytes while syncing on next audio frame Nov 2 00:07:06 gorgias vdr[20670]: cAudioRepacker(0xC1): skipped 118 bytes to sync on next audio frame Nov 2 00:07:06 gorgias vdr[20668]: cAudioRepacker(0xC0): skipped 572 bytes while syncing on next audio frame Nov 2 00:07:06 gorgias vdr[20668]: cAudioRepacker(0xC1): skipped 1468 bytes while syncing on next audio frame Nov 2 00:07:06 gorgias vdr[20668]: TS continuity error (8) Nov 2 00:07:06 gorgias vdr[20668]: TS continuity error (2) Nov 2 00:07:06 gorgias vdr[20668]: cAudioRepacker(0xC1): skipped 1468 bytes while syncing on next audio frame Nov 2 00:07:06 gorgias vdr[20668]: cAudioRepacker(0xC1): skipped 118 bytes to sync on next audio frame Nov 2 00:07:15 gorgias vdr[20650]: CAM: Viaccess, 01, 0500, 0500 Nov 2 00:07:22 gorgias vdr[20670]: cAudioRepacker(0xC1): skipped 558 bytes to sync on next audio frame Nov 2 00:07:22 gorgias vdr[20668]: cAudioRepacker(0xC1): skipped 558 bytes to sync on next audio frame Nov 2 00:07:22 gorgias vdr[20670]: cAudioRepacker(0xC0): skipped 4 bytes to sync on next audio frame Nov 2 00:07:22 gorgias vdr[20668]: cAudioRepacker(0xC0): skipped 4 bytes to sync on next audio frame Nov 2 00:10:00 gorgias /USR/SBIN/CRON[20704]: (root) CMD (/usr/local/bin/vcr-kontrolle) Nov 2 00:10:00 gorgias vdr[20670]: recording thread ended (pid=20670, tid=213001) Nov 2 00:10:00 gorgias vdr[20669]: file writer thread ended (pid=20669, tid=196614) Nov 2 00:10:00 gorgias vdr[20646]: cTS2PES got 0 TS errors, 1 TS continuity errors Nov 2 00:10:00 gorgias vdr[20646]: cTS2PES got 0 TS errors, 1 TS continuity errors Nov 2 00:10:00 gorgias vdr[20646]: buffer stats: 128028 (1%) used Nov 2 00:10:00 gorgias vdr[20646]: timer 6 (42 2355-0010 'Testauf2') stop
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.
Hi,
Wolfgang Goeller wrote:
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?
No I got definitely more - don't know why. My Machine is AMD Athlon(tm) XP 2000+ based with 750 MB OS is SuSE 9.0 The only plugin for vdr is remote-plugin. My recorder-card is a Hauppauge Nexus Recording is done to a software Raid 0 - array of two disks. The system resides on a separate disk. There is no other disk-activity than just that of the recording. On the machine there is as long as recording is done next to no activity (neither disk nor anything else). My CPU is according to top between 80 and 90% idle during records Typically: 15-19% system 0-0.3% user Tasks: 77 total, 6 running, 67 sleeping, 5 stopped
I changed remux.c according to your proposal and started a new recording - swiss channel already tuned in from the previous recording. It started without any cAudioRepacker-error but after 7 Minutes I got the following messages: (( BTW: after the recording ended, the messages showed up again)) (Note the CAM - message!)
Strange is that there are TS continuity errors which typically indicate dropped data. But I'm clueless how these could be related to CAM.
@Klaus: do you have any idea?
Nov 2 00:07:06 gorgias vdr[20670]: cAudioRepacker(0xC0): skipped 572 bytes while syncing on next audio frame Nov 2 00:07:06 gorgias vdr[20670]: cAudioRepacker(0xC1): skipped 1468 bytes while syncing on next audio frame Nov 2 00:07:06 gorgias vdr[20670]: TS continuity error (8) Nov 2 00:07:06 gorgias vdr[20670]: TS continuity error (2) Nov 2 00:07:06 gorgias vdr[20670]: cAudioRepacker(0xC1): skipped 1468 bytes while syncing on next audio frame Nov 2 00:07:06 gorgias vdr[20670]: cAudioRepacker(0xC1): skipped 118 bytes to sync on next audio frame Nov 2 00:07:06 gorgias vdr[20668]: cAudioRepacker(0xC0): skipped 572 bytes while syncing on next audio frame Nov 2 00:07:06 gorgias vdr[20668]: cAudioRepacker(0xC1): skipped 1468 bytes while syncing on next audio frame Nov 2 00:07:06 gorgias vdr[20668]: TS continuity error (8) Nov 2 00:07:06 gorgias vdr[20668]: TS continuity error (2) Nov 2 00:07:06 gorgias vdr[20668]: cAudioRepacker(0xC1): skipped 1468 bytes while syncing on next audio frame Nov 2 00:07:06 gorgias vdr[20668]: cAudioRepacker(0xC1): skipped 118 bytes to sync on next audio frame Nov 2 00:07:15 gorgias vdr[20650]: CAM: Viaccess, 01, 0500, 0500 Nov 2 00:07:22 gorgias vdr[20670]: cAudioRepacker(0xC1): skipped 558 bytes to sync on next audio frame Nov 2 00:07:22 gorgias vdr[20668]: cAudioRepacker(0xC1): skipped 558 bytes to sync on next audio frame Nov 2 00:07:22 gorgias vdr[20670]: cAudioRepacker(0xC0): skipped 4 bytes to sync on next audio frame Nov 2 00:07:22 gorgias vdr[20668]: cAudioRepacker(0xC0): skipped 4 bytes to sync on next audio frame Nov 2 00:10:00 gorgias /USR/SBIN/CRON[20704]: (root) CMD (/usr/local/bin/vcr-kontrolle) Nov 2 00:10:00 gorgias vdr[20670]: recording thread ended (pid=20670, tid=213001) Nov 2 00:10:00 gorgias vdr[20669]: file writer thread ended (pid=20669, tid=196614) Nov 2 00:10:00 gorgias vdr[20646]: cTS2PES got 0 TS errors, 1 TS continuity errors Nov 2 00:10:00 gorgias vdr[20646]: cTS2PES got 0 TS errors, 1 TS continuity errors Nov 2 00:10:00 gorgias vdr[20646]: buffer stats: 128028 (1%) used Nov 2 00:10:00 gorgias vdr[20646]: timer 6 (42 2355-0010 'Testauf2') stop
Bye.
Reinhard Nissl wrote:
Hi,
Wolfgang Goeller wrote:
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?
No I got definitely more - don't know why. My Machine is AMD Athlon(tm) XP 2000+ based with 750 MB OS is SuSE 9.0 The only plugin for vdr is remote-plugin. My recorder-card is a Hauppauge Nexus Recording is done to a software Raid 0 - array of two disks. The system resides on a separate disk. There is no other disk-activity than just that of the recording. On the machine there is as long as recording is done next to no activity (neither disk nor anything else). My CPU is according to top between 80 and 90% idle during records Typically: 15-19% system 0-0.3% user Tasks: 77 total, 6 running, 67 sleeping, 5 stopped
I changed remux.c according to your proposal and started a new recording - swiss channel already tuned in from the previous recording. It started without any cAudioRepacker-error but after 7 Minutes I got the following messages: (( BTW: after the recording ended, the messages showed up again)) (Note the CAM - message!)
Strange is that there are TS continuity errors which typically indicate dropped data. But I'm clueless how these could be related to CAM.
@Klaus: do you have any idea?
I'm afraid no. The CAM stuff in VDR only controls the CAM operation and doesn't actively do anything to the a/v data.
One possible test would be to completely turn off the cRepackers and see whether this leads to an error free behavior.
Klaus
-
Klaus Schmidinger -
Reinhard Nissl -
Wolfgang Goeller