Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK] [PROGRESS :) ]
On 05.09.2010 21:59, Simon Baxter wrote: Looks like there are TS packets in your stream that are marked as "scrambled", but not unscrambled by the CAM. Do you have any CAM in your system at all? Yes. System has 2x TT-1501-C cards and Alphacrypt CAMS Are the channels where this happens scrambled? Yes Do these channels have separate VPID and PPID? channels.conf looks like: ONE;T:578000:C0M64:C:6900:1305+1205=2:1405=...@4:579:606:1005:182:10:0 TV2;T:578000:C0M64:C:6900:1306+1206=2:1406=...@4:580:606:1006:182:10:0 TV3;T:578000:C0M64:C:6900:1303=2:14...@4:712:606,5601:1003:182:10:0 Does the problem go away if, instead of the above change, you comment out the line (Channel->Ppid() == Channel->Vpid() || AddPid(Channel->Ppid())) && in cReceiver::AddPids()? Yes - that fixes the problem ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK] [PROGRESS :) ]
On 05.09.2010 21:59, Simon Baxter wrote:
>> Looks like there are TS packets in your stream that are marked as
>> "scrambled", but not unscrambled by the CAM.
>>
>> Do you have any CAM in your system at all?
>
> Yes. System has 2x TT-1501-C cards and Alphacrypt CAMS
>
>> Are the channels where this happens scrambled?
> Yes
>
>> Do these channels have separate VPID and PPID?
> channels.conf looks like:
> ONE;T:578000:C0M64:C:6900:1305+1205=2:1405=...@4:579:606:1005:182:10:0
> TV2;T:578000:C0M64:C:6900:1306+1206=2:1406=...@4:580:606:1006:182:10:0
> TV3;T:578000:C0M64:C:6900:1303=2:14...@4:712:606,5601:1003:182:10:0
>
>
>> Does the problem go away if, instead of the above change, you
>> comment out the line
>>
>> (Channel->Ppid() == Channel->Vpid() || AddPid(Channel->Ppid())) &&
>>
>> in cReceiver::AddPids()?
>
> I can't find that in cReceiver::AddPids()
>
> Do you mean in "bool cReceiver::SetPids(const cChannel *Channel)":
> bool cReceiver::SetPids(const cChannel *Channel)
> {
> numPids = 0;
> if (Channel) {
> channelID = Channel->GetChannelID();
> return AddPid(Channel->Vpid()) &&
> //(Channel->Ppid() == Channel->Vpid() ||
> AddPid(Channel->Ppid())) &&
Yes.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK] [PROGRESS :) ]
Looks like there are TS packets in your stream that are marked as
"scrambled", but not unscrambled by the CAM.
Do you have any CAM in your system at all?
Yes. System has 2x TT-1501-C cards and Alphacrypt CAMS
Are the channels where this happens scrambled?
Yes
Do these channels have separate VPID and PPID?
channels.conf looks like:
ONE;T:578000:C0M64:C:6900:1305+1205=2:1405=...@4:579:606:1005:182:10:0
TV2;T:578000:C0M64:C:6900:1306+1206=2:1406=...@4:580:606:1006:182:10:0
TV3;T:578000:C0M64:C:6900:1303=2:14...@4:712:606,5601:1003:182:10:0
Does the problem go away if, instead of the above change, you
comment out the line
(Channel->Ppid() == Channel->Vpid() || AddPid(Channel->Ppid())) &&
in cReceiver::AddPids()?
I can't find that in cReceiver::AddPids()
Do you mean in "bool cReceiver::SetPids(const cChannel *Channel)":
bool cReceiver::SetPids(const cChannel *Channel)
{
numPids = 0;
if (Channel) {
channelID = Channel->GetChannelID();
return AddPid(Channel->Vpid()) &&
//(Channel->Ppid() == Channel->Vpid() ||
AddPid(Channel->Ppid())) &&
?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK] [PROGRESS :) ]
On 09/03/10 22:12, Simon Baxter wrote:
> ...
> So I've managed to get vdr-1.7.15 working just fine now, by disabling
> this scramble check in device.c. Bit of a dirty hack!!!
>
>
>
>> Here's what I changed in device.c
>>
>> void cDevice::Action(void)
>> {
>> if (Running() && OpenDvr()) {
>> while (Running()) {
>> // Read data from the DVR device:
>> uchar *b = NULL;
>> if (GetTSPacket(b)) {
>> if (b) {
>> int Pid = TsPid(b);
>> // Check whether the TS packets are scrambled:
>> bool DetachReceivers = false;
>> bool DescramblingOk = false;
>> int CamSlotNumber = 0;
>> if (startScrambleDetection) {
>> cCamSlot *cs = CamSlot();
>>CamSlotNumber = cs ? cs->SlotNumber() : 0;
>> //if (CamSlotNumber) {
>> // bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL;
>> // int t = time(NULL) - startScrambleDetection;
>> // if (Scrambled) {
>> // if (t > TS_SCRAMBLING_TIMEOUT)
>> // DetachReceivers = true;
>> // }
>> // else if (t > TS_SCRAMBLING_TIME_OK) {
>> // DescramblingOk = true;
>> // startScrambleDetection = 0;
>> // }
>> // }
>> }
>> // Distribute the packet to all attached receivers:
>> Lock();
Looks like there are TS packets in your stream that are marked as
"scrambled", but not unscrambled by the CAM.
Do you have any CAM in your system at all?
Are the channels where this happens scrambled?
Do these channels have separate VPID and PPID?
Does the problem go away if, instead of the above change, you
comment out the line
(Channel->Ppid() == Channel->Vpid() || AddPid(Channel->Ppid())) &&
in cReceiver::AddPids()?
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK] [PROGRESS :) ]
// Check whether the TS packets are scrambled:
Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here.
This could be caused by recording the PCR packets since version 1.7.12.
To debug this, just disable this check, and/or put in some debug
printouts.
Thanks Klaus
I've commented out the below section in device.c, and I now get continuous
video, but some video skips and lots of:
Sep 3 21:36:29 freddy vdr: [31301] cVideoRepacker: operating in MPEG1/2
mode
Sep 3 21:36:29 freddy vdr: [31301] cVideoRepacker: switching to MPEG1/2
mode
Sep 3 21:36:29 freddy vdr: [31301] cVideoRepacker: operating in MPEG1/2
mode
This cVideoRepacker problem has also been fixed with the attached patch.
So I've managed to get vdr-1.7.15 working just fine now, by disabling this
scramble check in device.c. Bit of a dirty hack!!!
Here's what I changed in device.c
void cDevice::Action(void)
{
if (Running() && OpenDvr()) {
while (Running()) {
// Read data from the DVR device:
uchar *b = NULL;
if (GetTSPacket(b)) {
if (b) {
int Pid = TsPid(b);
// Check whether the TS packets are scrambled:
bool DetachReceivers = false;
bool DescramblingOk = false;
int CamSlotNumber = 0;
if (startScrambleDetection) {
cCamSlot *cs = CamSlot();
CamSlotNumber = cs ? cs->SlotNumber() : 0;
//if (CamSlotNumber) {
// bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL;
// int t = time(NULL) - startScrambleDetection;
// if (Scrambled) {
// if (t > TS_SCRAMBLING_TIMEOUT)
// DetachReceivers = true;
// }
// else if (t > TS_SCRAMBLING_TIME_OK) {
// DescramblingOk = true;
// startScrambleDetection = 0;
// }
// }
}
// Distribute the packet to all attached receivers:
Lock();
Any ideas?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
vdr-xine-0.9.3-1.7.12.diff
Description: Binary data
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK]
// Check whether the TS packets are scrambled:
Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here.
This could be caused by recording the PCR packets since version 1.7.12.
To debug this, just disable this check, and/or put in some debug
printouts.
Thanks Klaus
I've commented out the below section in device.c, and I now get continuous
video, but some video skips and lots of:
Sep 3 21:36:29 freddy vdr: [31301] cVideoRepacker: operating in MPEG1/2
mode
Sep 3 21:36:29 freddy vdr: [31301] cVideoRepacker: switching to MPEG1/2
mode
Sep 3 21:36:29 freddy vdr: [31301] cVideoRepacker: operating in MPEG1/2
mode
Here's what I changed in device.c
void cDevice::Action(void)
{
if (Running() && OpenDvr()) {
while (Running()) {
// Read data from the DVR device:
uchar *b = NULL;
if (GetTSPacket(b)) {
if (b) {
int Pid = TsPid(b);
// Check whether the TS packets are scrambled:
bool DetachReceivers = false;
bool DescramblingOk = false;
int CamSlotNumber = 0;
if (startScrambleDetection) {
cCamSlot *cs = CamSlot();
CamSlotNumber = cs ? cs->SlotNumber() : 0;
//if (CamSlotNumber) {
// bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL;
// int t = time(NULL) - startScrambleDetection;
// if (Scrambled) {
// if (t > TS_SCRAMBLING_TIMEOUT)
// DetachReceivers = true;
// }
// else if (t > TS_SCRAMBLING_TIME_OK) {
// DescramblingOk = true;
// startScrambleDetection = 0;
// }
// }
}
// Distribute the packet to all attached receivers:
Lock();
Any ideas?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK]
My guess would be that the "DiscontinuityDetected: triggering soft
start"
is generated by the output device, and that causes the transfer mode
to be stoped and restarted. Maybe the output device chokes on something
in the TS stream?
The only place where a 3 second timeout plays a role that also
might cause a channel to become unavailable is in cDevice::Action(),
under
// Check whether the TS packets are scrambled:
Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here.
This could be caused by recording the PCR packets since version 1.7.12.
To debug this, just disable this check, and/or put in some debug
printouts.
I've added some markers in device.c as per:
// Check whether the TS packets are scrambled:
bool DetachReceivers = false;
bool DescramblingOk = false;
int CamSlotNumber = 0;
if (startScrambleDetection) {
cCamSlot *cs = CamSlot();
CamSlotNumber = cs ? cs->SlotNumber() : 0;
if (CamSlotNumber) {
bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL;
int t = time(NULL) - startScrambleDetection;
if (Scrambled) {
printf("scramble detect ONE");
if (t > TS_SCRAMBLING_TIMEOUT)
DetachReceivers = true;
}
else if (t > TS_SCRAMBLING_TIME_OK) {
printf("scramble detect TWO");
DescramblingOk = true;
startScrambleDetection = 0;
}
}
}
Am getting lots of "scramble detect ONE" messages as per above...
Now what?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK]
The only place where a 3 second timeout plays a role that also
might cause a channel to become unavailable is in cDevice::Action(),
under
// Check whether the TS packets are scrambled:
Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here.
This could be caused by recording the PCR packets since version 1.7.12.
To debug this, just disable this check, and/or put in some debug
printouts.
Klaus
How do I do this?
Is it as simple as :
- startScrambleDetection = 0;
+ startScrambleDetection = 1;
or comment out:
// if (startScrambleDetection) {
//cCamSlot *cs = CamSlot();
//CamSlotNumber = cs ? cs->SlotNumber() : 0;
//if (CamSlotNumber) {
// bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL;
// int t = time(NULL) - startScrambleDetection;
// if (Scrambled) {
// if (t > TS_SCRAMBLING_TIMEOUT)
// DetachReceivers = true;
// }
// else if (t > TS_SCRAMBLING_TIME_OK) {
// DescramblingOk = true;
// startScrambleDetection = 0;
// }
// }
//}
or something else?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK]
On 30.08.2010 02:05, Simon Baxter wrote: >> Am 29.08.2010 15:06, schrieb Klaus Schmidinger: >> DiscontinuityDetected: triggering soft start >>> >>> You may want to find out where this message comes from (it certainly >>> doesn't come from the core VDR). >> >> This is just an implementation detail of vdr-xine. >> Why am I getting a "SetPlayMode: 0" and "receiver on device 2 thread ended (pid=16557, tid=16633)" for no reason?? >>> >>> When a receiver is detached from a device, the play mode is set to >>> pmNone >>> (which is 0). >>> >>> My guess would be that the "DiscontinuityDetected: triggering soft >>> start" >>> is generated by the output device, and that causes the transfer mode >>> to be stoped and restarted. Maybe the output device chokes on something >>> in the TS stream? >> >> I doubt that vdr-xine does anything which would cause transfer >> mode to be stopped and restarted. > > I have the same problem (transfer mode stopping) with plain VDR (no > plugins) and a FF card. > i.e. works fine in vdr-1.7.(<=)11 but not in vdr-1.7.(>=12) > > Happy to do any captures etc - any suggestions?? The only place where a 3 second timeout plays a role that also might cause a channel to become unavailable is in cDevice::Action(), under // Check whether the TS packets are scrambled: Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here. This could be caused by recording the PCR packets since version 1.7.12. To debug this, just disable this check, and/or put in some debug printouts. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK]
Am 30.08.10 02:05, schrieb Simon Baxter: I have the same problem (transfer mode stopping) with plain VDR (no plugins) and a FF card. i.e. works fine in vdr-1.7.(<=)11 but not in vdr-1.7.(>=12) have you upgraded the firmware for your FF card, too? Bye, Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK]
Am 29.08.2010 15:06, schrieb Klaus Schmidinger: DiscontinuityDetected: triggering soft start You may want to find out where this message comes from (it certainly doesn't come from the core VDR). This is just an implementation detail of vdr-xine. Why am I getting a "SetPlayMode: 0" and "receiver on device 2 thread ended (pid=16557, tid=16633)" for no reason?? When a receiver is detached from a device, the play mode is set to pmNone (which is 0). My guess would be that the "DiscontinuityDetected: triggering soft start" is generated by the output device, and that causes the transfer mode to be stoped and restarted. Maybe the output device chokes on something in the TS stream? I doubt that vdr-xine does anything which would cause transfer mode to be stopped and restarted. I have the same problem (transfer mode stopping) with plain VDR (no plugins) and a FF card. i.e. works fine in vdr-1.7.(<=)11 but not in vdr-1.7.(>=12) Happy to do any captures etc - any suggestions?? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK]
Hi, Am 29.08.2010 15:06, schrieb Klaus Schmidinger: >> DiscontinuityDetected: triggering soft start > > You may want to find out where this message comes from (it certainly > doesn't come from the core VDR). This is just an implementation detail of vdr-xine. >> Why am I getting a "SetPlayMode: 0" and "receiver on device 2 thread >> ended (pid=16557, tid=16633)" for no reason?? > > When a receiver is detached from a device, the play mode is set to pmNone > (which is 0). > > My guess would be that the "DiscontinuityDetected: triggering soft start" > is generated by the output device, and that causes the transfer mode > to be stoped and restarted. Maybe the output device chokes on something > in the TS stream? I doubt that vdr-xine does anything which would cause transfer mode to be stopped and restarted. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK]
On 28.08.2010 03:07, Simon Baxter wrote: >> Summary of problem: >> vdr-1.7.12 or newer I get 3 seconds (or so) of live TV before screen >> goes blank >> system has TT-1501 abd TT-2300 cards - makes no difference whether >> xine plugin is running or not >> same problem running through TT-2300 FF card vdr-1.7.<=11 works fine. >> vdr-1.7.>=12 shows the problem > > I'm still no futher with this, can anyone please help? > > I turned on ci.c debugging to see what happens differently between > vdr-1.7.11 and vdr-1.7.15. > > 1.7.11 -> switch to channel 1 and on the console I see: > SetPlayMode: 0 > Slot 1: ==> Ca Pmt (3) 5 1 > 1: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 EB 01 00 07 01 > 09 04 06 06 E4 52 > Slot 1: ==> Ca Pmt (3) 4 1 > 1: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 > 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 > SetPlayMode: 1 > > in messages, I see: > Aug 28 12:53:15 freddy vdr: [17052] switching to channel 1 > Aug 28 12:53:15 freddy vdr: [17104] TS buffer on device 1 thread ended > (pid=17052, tid=17104) > Aug 28 12:53:15 freddy vdr: [17103] buffer stats: 80840 (3%) used > Aug 28 12:53:15 freddy vdr: [17103] receiver on device 1 thread ended > (pid=17052, tid=17103) > Aug 28 12:53:15 freddy vdr: [17105] receiver on device 1 thread started > (pid=17052, tid=17105) > Aug 28 12:53:15 freddy vdr: [17106] TS buffer on device 1 thread started > (pid=17052, tid=17106) > Aug 28 12:53:16 freddy vdr: [17105] cVideoRepacker: switching to MPEG1/2 > mode > Aug 28 12:53:16 freddy vdr: [17105] cVideoRepacker: operating in MPEG1/2 > mode > > i.e. ALL OK > > In vdr-1.7.15 on the same box, I see: > SetPlayMode: 0 > Slot 2: ==> Ca Pmt (3) 5 1 > 2: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 > 09 04 06 06 E4 54 > Slot 2: ==> Ca Pmt (3) 4 1 > 2: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 > 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 > SetPlayMode: 1 > [v] > DiscontinuityDetected: triggering soft start You may want to find out where this message comes from (it certainly doesn't come from the core VDR). > [vAVM]buffered 7.1 frames (v:12.2, a:7.1) > SetPlayMode: 0 > Slot 2: ==> Ca Pmt (3) 5 1 > 2: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 > 09 04 06 06 E4 54 > Slot 1: ==> Ca Pmt (3) 4 1 > 1: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 > 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 > SetPlayMode: 1 > [v] > DiscontinuityDetected: triggering soft start > [vAVM]buffered 7.3 frames (v:13.0, a:7.3) > SetPlayMode: 0 > Slot 1: ==> Ca Pmt (3) 5 1 > 1: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 > 09 04 06 06 E4 54 > Slot 2: ==> Ca Pmt (3) 4 1 > 2: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 > 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 > SetPlayMode: 1 > [v] > > and in messages: > Aug 28 12:50:10 freddy vdr: [16633] receiver on device 2 thread started > (pid=16557, tid=16633) > Aug 28 12:50:10 freddy vdr: [16634] TS buffer on device 2 thread started > (pid=16557, tid=16634) > Aug 28 12:50:11 freddy vdr: [16633] cVideoRepacker: switching to MPEG1/2 > mode > Aug 28 12:50:11 freddy vdr: [16633] cVideoRepacker: operating in MPEG1/2 > mode > Aug 28 12:50:14 freddy vdr: [16634] TS buffer on device 2 thread ended > (pid=16557, tid=16634) > Aug 28 12:50:14 freddy vdr: [16633] buffer stats: 192700 (9%) used > Aug 28 12:50:14 freddy vdr: [16633] receiver on device 2 thread ended > (pid=16557, tid=16633) > Aug 28 12:50:21 freddy vdr: [16557] switching to channel 1 > Aug 28 12:50:21 freddy vdr: [16635] receiver on device 1 thread started > (pid=16557, tid=16635) > Aug 28 12:50:21 freddy vdr: [16636] TS buffer on device 1 thread started > (pid=16557, tid=16636) > Aug 28 12:50:22 freddy vdr: [16635] cVideoRepacker: switching to MPEG1/2 > mode > Aug 28 12:50:22 freddy vdr: [16635] cVideoRepacker: operating in MPEG1/2 > mode > Aug 28 12:50:25 freddy vdr: [16636] TS buffer on device 1 thread ended > (pid=16557, tid=16636) > Aug 28 12:50:25 freddy vdr: [16635] buffer stats: 173712 (8%) used > Aug 28 12:50:25 freddy vdr: [16635] receiver on device 1 thread ended > (pid=16557, tid=16635) > > i.e. I get 3 second "bursts" of live TV, but blank screen as the > receiver threads restart > > Why am I getting a "SetPlayMode: 0" and "receiver on device 2 thread > ended (pid=16557, tid=16633)" for no reason?? When a receiver is detached from a device, the play mode is set to pmNone (which is 0). My guess would be that the "DiscontinuityDetected: triggering soft start" is generated by the output device, and that causes the transfer mode to be stoped and restarted. Maybe the output device chokes on something in the TS stream? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK]
Summary of problem: vdr-1.7.12 or newer I get 3 seconds (or so) of live TV before screen goes blank system has TT-1501 abd TT-2300 cards - makes no difference whether xine plugin is running or not same problem running through TT-2300 FF card vdr-1.7.<=11 works fine. vdr-1.7.>=12 shows the problem I'm still no futher with this, can anyone please help? I turned on ci.c debugging to see what happens differently between vdr-1.7.11 and vdr-1.7.15. 1.7.11 -> switch to channel 1 and on the console I see: SetPlayMode: 0 Slot 1: ==> Ca Pmt (3) 5 1 1: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 EB 01 00 07 01 09 04 06 06 E4 52 Slot 1: ==> Ca Pmt (3) 4 1 1: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1 in messages, I see: Aug 28 12:53:15 freddy vdr: [17052] switching to channel 1 Aug 28 12:53:15 freddy vdr: [17104] TS buffer on device 1 thread ended (pid=17052, tid=17104) Aug 28 12:53:15 freddy vdr: [17103] buffer stats: 80840 (3%) used Aug 28 12:53:15 freddy vdr: [17103] receiver on device 1 thread ended (pid=17052, tid=17103) Aug 28 12:53:15 freddy vdr: [17105] receiver on device 1 thread started (pid=17052, tid=17105) Aug 28 12:53:15 freddy vdr: [17106] TS buffer on device 1 thread started (pid=17052, tid=17106) Aug 28 12:53:16 freddy vdr: [17105] cVideoRepacker: switching to MPEG1/2 mode Aug 28 12:53:16 freddy vdr: [17105] cVideoRepacker: operating in MPEG1/2 mode i.e. ALL OK In vdr-1.7.15 on the same box, I see: SetPlayMode: 0 Slot 2: ==> Ca Pmt (3) 5 1 2: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 09 04 06 06 E4 54 Slot 2: ==> Ca Pmt (3) 4 1 2: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1 [v] DiscontinuityDetected: triggering soft start [vAVM]buffered 7.1 frames (v:12.2, a:7.1) SetPlayMode: 0 Slot 2: ==> Ca Pmt (3) 5 1 2: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 09 04 06 06 E4 54 Slot 1: ==> Ca Pmt (3) 4 1 1: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1 [v] DiscontinuityDetected: triggering soft start [vAVM]buffered 7.3 frames (v:13.0, a:7.3) SetPlayMode: 0 Slot 1: ==> Ca Pmt (3) 5 1 1: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 09 04 06 06 E4 54 Slot 2: ==> Ca Pmt (3) 4 1 2: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1 [v] and in messages: Aug 28 12:50:10 freddy vdr: [16633] receiver on device 2 thread started (pid=16557, tid=16633) Aug 28 12:50:10 freddy vdr: [16634] TS buffer on device 2 thread started (pid=16557, tid=16634) Aug 28 12:50:11 freddy vdr: [16633] cVideoRepacker: switching to MPEG1/2 mode Aug 28 12:50:11 freddy vdr: [16633] cVideoRepacker: operating in MPEG1/2 mode Aug 28 12:50:14 freddy vdr: [16634] TS buffer on device 2 thread ended (pid=16557, tid=16634) Aug 28 12:50:14 freddy vdr: [16633] buffer stats: 192700 (9%) used Aug 28 12:50:14 freddy vdr: [16633] receiver on device 2 thread ended (pid=16557, tid=16633) Aug 28 12:50:21 freddy vdr: [16557] switching to channel 1 Aug 28 12:50:21 freddy vdr: [16635] receiver on device 1 thread started (pid=16557, tid=16635) Aug 28 12:50:21 freddy vdr: [16636] TS buffer on device 1 thread started (pid=16557, tid=16636) Aug 28 12:50:22 freddy vdr: [16635] cVideoRepacker: switching to MPEG1/2 mode Aug 28 12:50:22 freddy vdr: [16635] cVideoRepacker: operating in MPEG1/2 mode Aug 28 12:50:25 freddy vdr: [16636] TS buffer on device 1 thread ended (pid=16557, tid=16636) Aug 28 12:50:25 freddy vdr: [16635] buffer stats: 173712 (8%) used Aug 28 12:50:25 freddy vdr: [16635] receiver on device 1 thread ended (pid=16557, tid=16635) i.e. I get 3 second "bursts" of live TV, but blank screen as the receiver threads restart Why am I getting a "SetPlayMode: 0" and "receiver on device 2 thread ended (pid=16557, tid=16633)" for no reason?? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
