Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
2: -- 01 01 80 02 01 00 . . . . . . Slot 2: receive data 1/1 2: -- 01 01 81 01 01 2: -- 01 01 A0 07 01 91 04 00 40 00 41 80 02 01 80 . . . . . . . @ . A . . . . Slot 2: open session 00400041 ERROR: CAM 2: session for resource identifier 00400041 already exists (1/1)Slot 2: receive data 1/1 2: -- 01 01 81 01 01 2: -- 01 01 A0 0A 01 90 02 00 05 9F 88 00 01 00 80 02 01 00 . . . . . . . . . . . . . . . . . Slot 2: == Close MMI (5) id = 00 delay = -1 Slot 2: == Poll 2: -- 01 01 A0 01 01 2: -- 01 01 80 02 01 00 . . . . . . Slot 2: == Poll 2: -- 01 01 A0 01 01 2: -- 01 01 80 02 01 00 . . . . . . Slot 2: == Poll 2: -- 01 01 A0 01 01 2: -- 01 01 80 02 01 00 . . . . . . Slot 2: == Poll 2: -- 01 01 A0 01 01 2: -- 01 01 80 02 01 00 . . . . . . Slot 2: == Poll 2: -- 01 01 A0 01 01 Slot 2: == Ca Pmt (3) 3 4 2: -- 01 01 A0 10 01 90 02 00 03 9F 80 32 07 03 00 00 01 00 01 04 2: -- 01 01 80 02 01 00 . . . . . . This log is really to heavy to post it. Pse find attached a tarball of it. Pierre -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Klaus Schmidinger Envoyé : dimanche 4 mai 2008 17:59 À : vdr@linuxtv.org Objet : Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define On 05/04/08 16:40, Pierre-Yves Paranthoen (PERSO) wrote: One part of the pb is that my cam module is ramdomly identified under 1.7.0 that might be the reason why the info Application Info and Ca Pmt Reply is not in the log. VDR-1.7.0 most gives CAM 2: module present CAM 2: module ready instead of giving Aston Module 1.0300, 01, 0100,0100 (info taken from vdr-1.4.7). When it's correctly being identified and trying to access CAM informations under OSD, VDR-1.7 responds ERROR: Can't open CAM menu! A CAM reset gives then a basic information : 2 CAM ready and nothing else. Of course no decryption. Here is the log of matching my explainations : May 4 16:07:49 localhost vdr: [8251] CAM 2: module present May 4 16:07:50 localhost vdr: [8251] CAM 1: no module present May 4 16:07:50 localhost vdr: [8251] CAM 2: module ready May 4 16:07:54 localhost vdr: [8251] Slot 2: == Application Info (2) May 4 16:07:54 localhost vdr: [8251] CAM 2: Aston Module 1.0300, 01, 0100, 0100 So the application information is being received. I'm afraid I was looking at the wrong lines when telling you which 'dbgprotocol's to change. Please also change the ones in lines 696: dbgprotocol(Slot %d: == Ca Info (%d), Tc()-CamSlot()-SlotNumber(), SessionId()); 702: dbgprotocol( %04X, id); 713: dbgprotocol(\n); Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr vdr-1.7.0-debug.tar.bz2 Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
Added in device.c debug output to cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView) : GetDevice 2 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 2 0 1 -1 no usable CAM slots! GetDevice 2 0 1 -1 no usable CAM slots! GetDevice 2 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 2 0 1 -1 no usable CAM slots! GetDevice 2 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 1 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 1 0 1 -1 no usable CAM slots! GetDevice 1 0 1 -1 no usable CAM slots! GetDevice 1 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 2 0 1 -1 j = 1, i = 0, imp = 062C4C5A, Impact = device 0 GetDevice 2 0 1 -1 j = 1, i = 0, imp = 020C4C4A, Impact = device 0 GetDevice 3 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 3 0 1 -1 no usable CAM slots! GetDevice 3 0 1 -1 no usable CAM slots! GetDevice 3 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 3 0 1 -1 no usable CAM slots! GetDevice 4 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 4 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 5 0 1 -1 j = 0, i = 0, imp = 062C4C7E, Impact = device 0 GetDevice 5 0 1 -1 j = 0, i = 0, imp = 020C4C6E, Impact = device 0 GetDevice 6 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 6 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 6 0 1 -1 no usable CAM slots! GetDevice 7 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 7 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 7 0 1 -1 no usable CAM slots! GetDevice 8 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 8 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 8 0 1 -1 no usable CAM slots! GetDevice 9 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 9 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 9 0 1 -1 no usable CAM slots! GetDevice 9 0 1 -1 no usable CAM slots! GetDevice 10 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 10 0 1 -1 j = 1, i = 0, imp = 020C4C4B, Impact = device 0 GetDevice 10 0 1 -1 no usable CAM slots! GetDevice 10 0 1 -1 no usable CAM slots! and syslog gives : May 4 10:20:40 localhost vdr: [645] TS buffer on device 1 thread started (pid=390, tid=645) May 4 10:20:43 localhost vdr: [643] transfer thread ended (pid=390, tid=643) May 4 10:20:43 localhost vdr: [645] TS buffer on device 1 thread ended (pid=390, tid=645) May 4 10:20:43 localhost vdr: [644] buffer stats: 92308 (4%) used May 4 10:20:43 localhost vdr: [644] receiver on device 1 thread ended (pid=390, tid=644) May 4 10:20:50 localhost vdr: [390] switching to channel 3 May 4 10:20:50 localhost vdr: [390] buffer stats: 66364 (3%) used May 4 10:20:50 localhost vdr: [390] info: Channel not available! May 4 10:20:58 localhost vdr: [390] switching to channel 4 May 4 10:20:58 localhost vdr: [655] transfer thread started (pid=390, tid=655) May 4 10:20:58 localhost vdr: [656] receiver on device 1 thread started (pid=390, tid=656) May 4 10:20:58 localhost vdr: [657] TS buffer on device 1 thread started (pid=390, tid=657) May 4 10:20:58 localhost kernel: dvb_frontend_ioctl: DVBFE_GET_INFO May 4 10:20:58 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: fepriv-state=2 May 4 10:21:01 localhost vdr: [655] transfer thread ended (pid=390, tid=655) May 4 10:21:01 localhost vdr: [390] CAM 2: unassigned May 4 10:21:01 localhost vdr: [390] switching to channel 5 May 4 10:21:01 localhost vdr: [390] buffer stats: 64484 (3%) used May 4 10:21:02 localhost kernel: dvb_frontend_ioctl: DVBFE_GET_INFO May 4 10:21:02 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: fepriv-state=2 May 4 10:21:02 localhost vdr: [657] TS buffer on device 1 thread ended (pid=390, tid=657) May 4 10:21:02 localhost vdr: [656] buffer stats: 64108 (3%) used May 4 10:21:02 localhost vdr: [656] receiver on device 1 thread ended (pid=390, tid=656) May 4 10:21:04 localhost vdr: [390] CAM 2: assigned to device 1 May 4 10:21:04 localhost vdr: [390] switching to channel 6 May 4 10:21:04 localhost vdr: [667] transfer thread started (pid=390, tid=667) May 4 10:21:04 localhost vdr: [668] receiver on device 1 thread started (pid=390, tid=668) May 4 10:21:04 localhost vdr: [669] TS buffer on device 1 thread started (pid=390, tid=669) May 4 10:21:04 localhost kernel: dvb_frontend_ioctl: DVBFE_GET_INFO May 4 10:21:04 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: fepriv-state=2 May 4 10:21:08 localhost vdr: [667] transfer thread ended (pid=390, tid=667) May 4 10:21:08 localhost vdr: [669] TS buffer on device 1 thread ended (pid=390, tid=669) May 4 10:21:08 localhost vdr: [668]
Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
I also increased values in #define TS_SCRAMBLING_CONTROL 0xC0 #define TS_SCRAMBLING_TIMEOUT 5 // seconds to wait until a TS becomes unscrambled #define TS_SCRAMBLING_TIME_OK15 // seconds before a Channel/CAM combination is marked as known to decrypt still the same. May 4 10:33:34 localhost vdr: [1348] info: Channel not available! May 4 10:33:45 localhost vdr: [1348] switching to channel 21 May 4 10:33:45 localhost vdr: [1535] transfer thread started (pid=1348, tid=1535) May 4 10:33:45 localhost vdr: [1536] receiver on device 1 thread started (pid=1348, tid=1536) May 4 10:33:46 localhost vdr: [1537] TS buffer on device 1 thread started (pid=1348, tid=1537) May 4 10:33:48 localhost vdr: [1352] ERROR: CAM 2: session for resource identifier 00400041 already exists (1/1) May 4 10:33:51 localhost vdr: [1535] transfer thread ended (pid=1348, tid=1535) May 4 10:33:51 localhost vdr: [1537] TS buffer on device 1 thread ended (pid=1348, tid=1537) May 4 10:33:51 localhost vdr: [1536] buffer stats: 126148 (6%) used May 4 10:33:51 localhost vdr: [1536] receiver on device 1 thread ended (pid=1348, tid=1536) May 4 10:33:56 localhost vdr: [1348] switching to channel 21 May 4 10:33:56 localhost vdr: [1348] buffer stats: 45120 (2%) used May 4 10:33:56 localhost vdr: [1348] info: Channel not available! May 4 10:34:07 localhost vdr: [1348] switching to channel 21 May 4 10:34:07 localhost vdr: [1556] transfer thread started (pid=1348, tid=1556) May 4 10:34:07 localhost vdr: [1557] receiver on device 1 thread started (pid=1348, tid=1557) May 4 10:34:07 localhost vdr: [1558] TS buffer on device 1 thread started (pid=1348, tid=1558) May 4 10:34:09 localhost vdr: [1352] ERROR: CAM 2: session for resource identifier 00400041 already exists (1/1) May 4 10:34:13 localhost vdr: [1556] transfer thread ended (pid=1348, tid=1556) May 4 10:34:13 localhost vdr: [1558] TS buffer on device 1 thread ended (pid=1348, tid=1558) May 4 10:34:13 localhost vdr: [1557] buffer stats: 121260 (5%) used May 4 10:34:13 localhost vdr: [1557] receiver on device 1 thread ended (pid=1348, tid=1557) May 4 10:34:18 localhost vdr: [1348] switching to channel 21 May 4 10:34:18 localhost vdr: [1348] buffer stats: 44744 (2%) used May 4 10:34:18 localhost vdr: [1348] info: Channel not available! May 4 10:34:18 localhost kernel: dvb_frontend_ioctl: DVBFE_GET_INFO May 4 10:34:18 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: fepriv-state=2 Pierre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
On 05/04/08 10:34, Pierre-Yves Paranthoen (PERSO) wrote: I also increased values in #define TS_SCRAMBLING_CONTROL 0xC0 #define TS_SCRAMBLING_TIMEOUT 5 // seconds to wait until a TS becomes unscrambled #define TS_SCRAMBLING_TIME_OK15 // seconds before a Channel/CAM combination is marked as known to decrypt still the same. May 4 10:33:34 localhost vdr: [1348] info: Channel not available! May 4 10:33:45 localhost vdr: [1348] switching to channel 21 May 4 10:33:45 localhost vdr: [1535] transfer thread started (pid=1348, tid=1535) May 4 10:33:45 localhost vdr: [1536] receiver on device 1 thread started (pid=1348, tid=1536) May 4 10:33:46 localhost vdr: [1537] TS buffer on device 1 thread started (pid=1348, tid=1537) May 4 10:33:48 localhost vdr: [1352] ERROR: CAM 2: session for resource identifier 00400041 already exists (1/1) This is getting stranger by the minute... Why would the CAM try to establish another MMI resource? Are you sure this is an unpatched version of VDR 1.7.0 (except for the patch to device.c I gave you)? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
On 05/04/08 10:23, Pierre-Yves Paranthoen (PERSO) wrote:
Added in device.c debug output to cDevice::GetDevice(const cChannel
*Channel, int Priority, bool LiveView) :
GetDevice 2 0 1 -1
j = 1, i = 0, imp = 020C4C4B, Impact =
device 0
GetDevice 2 0 1 -1
no usable CAM slots!
...
Looks like for some reason the CAM is not usable at this time.
Please apply the attched patch instead of the previous one.
It produces additional output and writes it into the syslog,
so that it will be in sync with the other log messages.
Klaus
--- device.c 2008/04/12 14:12:14 2.2
+++ device.c 2008/05/04 09:24:16
@@ -372,26 +372,35 @@
cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView)
{
+ dsyslog(GetDevice %d %d %d %d %04X, Channel-Number(), Priority, LiveView, avoidDevice ? avoidDevice-CardIndex() : -1, Channel-Ca());//XXX
cDevice *AvoidDevice = avoidDevice;
avoidDevice = NULL;
// Collect the current priorities of all CAM slots that can decrypt the channel:
int NumCamSlots = CamSlots.Count();
+ dsyslog(NumCamSlots = %d, NumCamSlots);//XXX
int SlotPriority[NumCamSlots];
int NumUsableSlots = 0;
if (Channel-Ca() = CA_ENCRYPTED_MIN) {
for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = CamSlots.Next(CamSlot)) {
SlotPriority[CamSlot-Index()] = MAXPRIORITY + 1; // assumes it can't be used
if (CamSlot-ModuleStatus() == msReady) {
+dsyslog(CAM %d ready, CamSlot-Index());//XXX
if (CamSlot-ProvidesCa(Channel-Caids())) {
+ dsyslog(CAM %d provides CA, CamSlot-Index());//XXX
if (!ChannelCamRelations.CamChecked(Channel-GetChannelID(), CamSlot-SlotNumber())) {
SlotPriority[CamSlot-Index()] = CamSlot-Priority();
NumUsableSlots++;
+ dsyslog(NumUsableSlots = %d, NumUsableSlots);//XXX
}
+ else dsyslog(ChannelCamRelations.CamChecked(%s, %d) = 0, *Channel-GetChannelID().ToString(), CamSlot-SlotNumber());//XXX
}
}
+ else dsyslog(CAM %d not ready, CamSlot-Index());//XXX
}
if (!NumUsableSlots)
+{dsyslog(no usable CAM slots!);//XXX
return NULL; // no CAM is able to decrypt this channel
+}//XXX
}
bool NeedsDetachReceivers = false;
@@ -432,6 +441,7 @@
imp = 1; imp |= NumUsableSlots ? 0 : device[i]-HasCi(); // avoid cards with Common Interface for FTA channels
imp = 1; imp |= device[i]-HasDecoder(); // avoid full featured cards
imp = 1; imp |= NumUsableSlots ? !ChannelCamRelations.CamDecrypt(Channel-GetChannelID(), j + 1) : 0; // prefer CAMs that are known to decrypt this channel
+ dsyslog(j = %d, i = %d, imp = %08X, Impact = %08X, j, i, imp, Impact);//XXX
if (imp Impact) {
// This device has less impact than any previous one, so we take it.
Impact = imp;
@@ -446,6 +456,7 @@
break; // no CAM necessary, so just one loop over the devices
}
if (d) {
+ dsyslog(device %d, d-CardIndex());//XXX
if (NeedsDetachReceivers)
d-DetachAllReceivers();
if (s) {
@@ -460,6 +471,7 @@
else if (d-CamSlot() !d-CamSlot()-IsDecrypting())
d-CamSlot()-Assign(NULL);
}
+ else dsyslog(no device found);//XXX
return d;
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
This is getting stranger by the minute... Why would the CAM try to establish another MMI resource? Are you sure this is an unpatched version of VDR 1.7.0 (except for the patch to device.c I gave you)? Klaus It's a native unpatched vdr-1.7.0. I try the patch Pierre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
On 05/04/08 15:31, Pierre-Yves Paranthoen (PERSO) wrote: Here are the results with the device.c patch you gave me : ... May 4 15:28:08 localhost vdr: [7030] edited channel 1 TF1;CSAT:11895:vC34O0S0:S19.2E:27500:171:124=fra,125=eng:53:0:8371:1:1074:0 ... May 4 15:28:29 localhost vdr: [7030] switching to channel 1 May 4 15:28:29 localhost vdr: [7030] GetDevice 1 0 1 -1 May 4 15:28:29 localhost vdr: [7030] NumCamSlots = 2 May 4 15:28:29 localhost vdr: [7030] j = 0, i = 0, imp = 020C4C6E, Impact = May 4 15:28:29 localhost vdr: [7030] device 0 ... May 4 15:28:32 localhost vdr: [7036] changing caids of channel 1 from 0 to 500,100 May 4 15:28:32 localhost vdr: [7030] retuning due to modification of channel 1 May 4 15:28:32 localhost vdr: [7030] switching to channel 1 May 4 15:28:32 localhost vdr: [7030] GetDevice 1 0 1 -1 0500 May 4 15:28:32 localhost vdr: [7030] NumCamSlots = 2 May 4 15:28:32 localhost vdr: [7030] CAM 0 not ready May 4 15:28:32 localhost vdr: [7030] CAM 1 ready May 4 15:28:32 localhost vdr: [7030] no usable CAM slots! May 4 15:28:32 localhost vdr: [7030] info: Channel not available! After changing the CA id of channel 1 to '0', the first device is chosen. Then the CA id is automatically updated to 500,100 and the channel is retuned. CAM 2 (index 1) is ready, but apparently doesn't provide CA id 500 or 100. What I'm missing in your log is the actual application information message of your CAM - something like CAM 2: AlphaCrypt, 01, 4A20, 4A20 Please change the 'dbgprotocol' to 'dsyslog' in the following lines of ci.c: 515: dbgprotocol(Slot %d: == Application Info (%d)\n, Tc()-CamSlot()-SlotNumber(), SessionId()); 721: dbgprotocol(Slot %d: == Ca Pmt Reply (%d), Tc()-CamSlot()-SlotNumber(), SessionId()); 731: dbgprotocol( %d, pnr); 735: dbgprotocol( %02X, *d); 752: dbgprotocol( %02X, caepl); 761: dbgprotocol( %d=%02X, pid, caees); 772: dbgprotocol(\n); and repeat the test. Make sure the Application Info and Ca Pmt Reply messages are in your log excerpt. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
: [8247] CAM 2: 'Votre choix, svp' May 4 16:10:33 localhost vdr: [8247] CAM 2: select 0 May 4 16:10:35 localhost vdr: [8247] CAM 2: Menu -- May 4 16:10:35 localhost vdr: [8247] CAM 2: 'Aston Module' May 4 16:10:35 localhost vdr: [8247] CAM 2: 'Interrogation de la carte: attendez' May 4 16:10:36 localhost vdr: [8247] CAM 2: Menu -- May 4 16:10:36 localhost vdr: [8247] CAM 2: 'Aston Module/Consultation des droits' May 4 16:10:36 localhost vdr: [8247] CAM 2: 'Liste des services pour la carte N°xxx.xxx.xxx' May 4 16:10:36 localhost vdr: [8247] CAM 2: 'CANALSAT' May 4 16:10:36 localhost vdr: [8247] CAM 2: 'CANAL+' May 4 16:10:36 localhost vdr: [8247] CAM 2: 'CANALPRO' May 4 16:10:36 localhost vdr: [8247] CAM 2: 'CSAT 1' May 4 16:10:36 localhost vdr: [8247] CAM 2: 'CSAT 2' May 4 16:10:36 localhost vdr: [8247] CAM 2: 'Votre choix, svp' May 4 16:10:39 localhost vdr: [8247] CAM 2: select 0 May 4 16:10:44 localhost vdr: [8247] ERROR: CAM not responding! May 4 16:10:48 localhost vdr: [8247] confirm: CAM is in use - really reset? May 4 16:10:48 localhost vdr: [8247] warning: CAM is in use - really reset? May 4 16:10:51 localhost vdr: [8247] confirmed May 4 16:10:52 localhost vdr: [8251] CAM 2: module present May 4 16:10:53 localhost vdr: [8251] CAM 2: module ready I can change the 'dbgprotocol' to 'dsyslog' under VDR-1.4.7 give you the results if it might helps. Pierre -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Klaus Schmidinger Envoyé : dimanche 4 mai 2008 16:02 À : vdr@linuxtv.org Objet : Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define On 05/04/08 15:31, Pierre-Yves Paranthoen (PERSO) wrote: Here are the results with the device.c patch you gave me : ... May 4 15:28:08 localhost vdr: [7030] edited channel 1 TF1;CSAT:11895:vC34O0S0:S19.2E:27500:171:124=fra,125=eng:53:0:8371:1:1 074:0 ... May 4 15:28:29 localhost vdr: [7030] switching to channel 1 May 4 15:28:29 localhost vdr: [7030] GetDevice 1 0 1 -1 May 4 15:28:29 localhost vdr: [7030] NumCamSlots = 2 May 4 15:28:29 localhost vdr: [7030] j = 0, i = 0, imp = 020C4C6E, Impact = May 4 15:28:29 localhost vdr: [7030] device 0 ... May 4 15:28:32 localhost vdr: [7036] changing caids of channel 1 from 0 to 500,100 May 4 15:28:32 localhost vdr: [7030] retuning due to modification of channel 1 May 4 15:28:32 localhost vdr: [7030] switching to channel 1 May 4 15:28:32 localhost vdr: [7030] GetDevice 1 0 1 -1 0500 May 4 15:28:32 localhost vdr: [7030] NumCamSlots = 2 May 4 15:28:32 localhost vdr: [7030] CAM 0 not ready May 4 15:28:32 localhost vdr: [7030] CAM 1 ready May 4 15:28:32 localhost vdr: [7030] no usable CAM slots! May 4 15:28:32 localhost vdr: [7030] info: Channel not available! After changing the CA id of channel 1 to '0', the first device is chosen. Then the CA id is automatically updated to 500,100 and the channel is retuned. CAM 2 (index 1) is ready, but apparently doesn't provide CA id 500 or 100. What I'm missing in your log is the actual application information message of your CAM - something like CAM 2: AlphaCrypt, 01, 4A20, 4A20 Please change the 'dbgprotocol' to 'dsyslog' in the following lines of ci.c: 515: dbgprotocol(Slot %d: == Application Info (%d)\n, Tc()-CamSlot()-SlotNumber(), SessionId()); 721: dbgprotocol(Slot %d: == Ca Pmt Reply (%d), Tc()-CamSlot()-SlotNumber(), SessionId()); 731: dbgprotocol( %d, pnr); 735: dbgprotocol( %02X, *d); 752: dbgprotocol( %02X, caepl); 761: dbgprotocol( %d=%02X, pid, caees); 772: dbgprotocol(\n); and repeat the test. Make sure the Application Info and Ca Pmt Reply messages are in your log excerpt. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
On 05/04/08 16:40, Pierre-Yves Paranthoen (PERSO) wrote: One part of the pb is that my cam module is ramdomly identified under 1.7.0 that might be the reason why the info Application Info and Ca Pmt Reply is not in the log. VDR-1.7.0 most gives CAM 2: module present CAM 2: module ready instead of giving Aston Module 1.0300, 01, 0100,0100 (info taken from vdr-1.4.7). When it's correctly being identified and trying to access CAM informations under OSD, VDR-1.7 responds ERROR: Can't open CAM menu! A CAM reset gives then a basic information : 2 CAM ready and nothing else. Of course no decryption. Here is the log of matching my explainations : May 4 16:07:49 localhost vdr: [8251] CAM 2: module present May 4 16:07:50 localhost vdr: [8251] CAM 1: no module present May 4 16:07:50 localhost vdr: [8251] CAM 2: module ready May 4 16:07:54 localhost vdr: [8251] Slot 2: == Application Info (2) May 4 16:07:54 localhost vdr: [8251] CAM 2: Aston Module 1.0300, 01, 0100, 0100 So the application information is being received. I'm afraid I was looking at the wrong lines when telling you which 'dbgprotocol's to change. Please also change the ones in lines 696: dbgprotocol(Slot %d: == Ca Info (%d), Tc()-CamSlot()-SlotNumber(), SessionId()); 702: dbgprotocol( %04X, id); 713: dbgprotocol(\n); Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
On 04/25/08 18:34, Pierre-Yves Paranthoen (PERSO) wrote: I increased the values in ci.c. A bit better but, still no decryption and channel not available : #define MODULE_CHECK_INTERVAL 1 // ms #define MODULE_RESET_TIMEOUT5 // s gives under 1.7.0 : Apr 25 18:29:04 localhost vdr: [7317] CAM 2: module ready Apr 25 18:29:11 localhost vdr: [7317] CAM 2: doesn't reply to QUERY - only a single channel can be decrypted Apr 25 18:29:11 localhost vdr: [7313] switching to channel 2 Apr 25 18:29:11 localhost vdr: [7313] CAM 2: assigned to device 1 Apr 25 18:29:11 localhost vdr: [7328] transfer thread started (pid=7313, tid=7328) Apr 25 18:29:11 localhost vdr: [7329] receiver on device 1 thread started (pid=7313, tid=7329) Apr 25 18:29:11 localhost vdr: [7330] TS buffer on device 1 thread started (pid=7313, tid=7330) Apr 25 18:29:11 localhost vdr: [7313] setting watchdog timer to 20 seconds Apr 25 18:29:12 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 71 10 01 01 13 01 20 14 03 00 83 00 Apr 25 18:29:12 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 70 10 01 01 13 01 20 14 03 03 0B 00 Apr 25 18:29:12 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 72 10 01 01 13 01 20 14 03 02 26 10 Apr 25 18:29:12 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 6F 10 01 01 13 01 20 14 03 03 28 20 Apr 25 18:29:12 localhost vdr: [7319] CAM: 88C0 212012 8801 0100 1 - 09 89 01 00 F5 8C 33 17 FF 40 00 00 00 08 00 80 44 24 99 F5 88 33 15 FF 00 00 0C 00 00 00 00 06 24 99 F5 8B 33 11 FF 00 00 0E 02 00 00 00 02 24 99 F5 8A A8 21 FF 20 00 01 00 00 00 04 4E 24 99 E5 EC 00 86 FF 00 00 00 Apr 25 18:29:13 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 DF 10 01 01 13 01 20 14 03 00 83 00 Apr 25 18:29:13 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 DD 10 01 01 13 01 20 14 03 03 0B 00 Apr 25 18:29:13 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 E0 10 01 01 13 01 20 14 03 02 26 10 Apr 25 18:29:13 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 DE 10 01 01 13 01 20 14 03 03 28 20 Apr 25 18:29:13 localhost vdr: [7319] CAM: 88C0 212012 8802 0100 1 - 09 89 01 00 F5 F9 33 17 FF 40 00 00 00 08 00 80 44 24 99 F5 F5 33 15 FF 00 00 0C 00 00 00 00 06 24 99 F5 F4 33 11 FF 00 00 0E 02 00 00 00 02 24 99 F5 F8 A8 21 FF 20 00 01 00 00 00 04 4E 24 99 E6 59 00 86 FF 00 00 00 Apr 25 18:29:14 localhost vdr: [7323] EPGSearch: timer conflict check started Apr 25 18:29:14 localhost vdr: [7323] EPGSearch: timer conflict check finished Apr 25 18:29:18 localhost vdr: [7313] max. latency time 1 seconds Apr 25 18:29:53 localhost vdr: [7322] connect from 192.168.3.245, port 53838 - accepted Apr 25 18:29:59 localhost vdr: [7328] transfer thread ended (pid=7313, tid=7328) Apr 25 18:30:00 localhost vdr: [7313] switching to channel 3 Apr 25 18:30:00 localhost vdr: [7313] buffer stats: 5640 (0%) used Apr 25 18:30:00 localhost vdr: [7330] TS buffer on device 1 thread ended (pid=7313, tid=7330) Apr 25 18:30:00 localhost vdr: [7329] buffer stats: 5264 (0%) used Apr 25 18:30:00 localhost vdr: [7334] transfer thread started (pid=7313, tid=7334) Apr 25 18:30:00 localhost vdr: [7329] receiver on device 1 thread ended (pid=7313, tid=7329) Apr 25 18:30:00 localhost vdr: [7335] receiver on device 1 thread started (pid=7313, tid=7335) Apr 25 18:30:00 localhost vdr: [7336] TS buffer on device 1 thread started (pid=7313, tid=7336) Apr 25 18:30:00 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 71 10 01 01 13 01 20 14 03 00 83 00 Apr 25 18:30:00 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 70 10 01 01 13 01 20 14 03 03 0B 00 Apr 25 18:30:00 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 72 10 01 01 13 01 20 14 03 02 26 10 Apr 25 18:30:00 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 6F 10 01 01 13 01 20 14 03 03 28 20 Apr 25 18:30:00 localhost vdr: [7319] CAM: 88C0 212012 8801 0100 1 - 09 89 01 00 F5 8C 33 17 FF 40 00 00 00 08 00 80 44 24 99 F5 88 33 15 FF 00 00 0C 00 00 00 00 06 24 99 F5 8B 33 11 FF 00 00 0E 02 00 00 00 02 24 99 F5 8A A8 21 FF 20 00 01 00 00 00 04 4E 24 99 E5 EC 00 86 FF 00 00 00 Apr 25 18:30:01 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 DF 10 01 01 13 01 20 14 03 00 83 00 Apr 25 18:30:01 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 DD 10 01 01 13 01 20 14 03 03 0B 00 Apr 25 18:30:01 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 E0 10 01 01 13 01 20 14 03 02 26 10 Apr 25 18:30:01 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 DE 10 01 01 13 01 20 14 03 03 28 20 Apr 25 18:30:01 localhost vdr: [7319] CAM: 88C0 212012 8802 0100 1 - 09 89 01 00 F5 F9 33 17 FF 40 00 00 00 08 00 80
Re: [vdr] Upgrading from 1.4.7 to 1.7.0 : enabling #define
I increased the values in ci.c. A bit better but, still no decryption and channel not available : #define MODULE_CHECK_INTERVAL 1 // ms #define MODULE_RESET_TIMEOUT5 // s gives under 1.7.0 : Apr 25 18:29:04 localhost vdr: [7317] CAM 2: module ready Apr 25 18:29:11 localhost vdr: [7317] CAM 2: doesn't reply to QUERY - only a single channel can be decrypted Apr 25 18:29:11 localhost vdr: [7313] switching to channel 2 Apr 25 18:29:11 localhost vdr: [7313] CAM 2: assigned to device 1 Apr 25 18:29:11 localhost vdr: [7328] transfer thread started (pid=7313, tid=7328) Apr 25 18:29:11 localhost vdr: [7329] receiver on device 1 thread started (pid=7313, tid=7329) Apr 25 18:29:11 localhost vdr: [7330] TS buffer on device 1 thread started (pid=7313, tid=7330) Apr 25 18:29:11 localhost vdr: [7313] setting watchdog timer to 20 seconds Apr 25 18:29:12 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 71 10 01 01 13 01 20 14 03 00 83 00 Apr 25 18:29:12 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 70 10 01 01 13 01 20 14 03 03 0B 00 Apr 25 18:29:12 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 72 10 01 01 13 01 20 14 03 02 26 10 Apr 25 18:29:12 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 6F 10 01 01 13 01 20 14 03 03 28 20 Apr 25 18:29:12 localhost vdr: [7319] CAM: 88C0 212012 8801 0100 1 - 09 89 01 00 F5 8C 33 17 FF 40 00 00 00 08 00 80 44 24 99 F5 88 33 15 FF 00 00 0C 00 00 00 00 06 24 99 F5 8B 33 11 FF 00 00 0E 02 00 00 00 02 24 99 F5 8A A8 21 FF 20 00 01 00 00 00 04 4E 24 99 E5 EC 00 86 FF 00 00 00 Apr 25 18:29:13 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 DF 10 01 01 13 01 20 14 03 00 83 00 Apr 25 18:29:13 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 DD 10 01 01 13 01 20 14 03 03 0B 00 Apr 25 18:29:13 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 E0 10 01 01 13 01 20 14 03 02 26 10 Apr 25 18:29:13 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 DE 10 01 01 13 01 20 14 03 03 28 20 Apr 25 18:29:13 localhost vdr: [7319] CAM: 88C0 212012 8802 0100 1 - 09 89 01 00 F5 F9 33 17 FF 40 00 00 00 08 00 80 44 24 99 F5 F5 33 15 FF 00 00 0C 00 00 00 00 06 24 99 F5 F4 33 11 FF 00 00 0E 02 00 00 00 02 24 99 F5 F8 A8 21 FF 20 00 01 00 00 00 04 4E 24 99 E6 59 00 86 FF 00 00 00 Apr 25 18:29:14 localhost vdr: [7323] EPGSearch: timer conflict check started Apr 25 18:29:14 localhost vdr: [7323] EPGSearch: timer conflict check finished Apr 25 18:29:18 localhost vdr: [7313] max. latency time 1 seconds Apr 25 18:29:53 localhost vdr: [7322] connect from 192.168.3.245, port 53838 - accepted Apr 25 18:29:59 localhost vdr: [7328] transfer thread ended (pid=7313, tid=7328) Apr 25 18:30:00 localhost vdr: [7313] switching to channel 3 Apr 25 18:30:00 localhost vdr: [7313] buffer stats: 5640 (0%) used Apr 25 18:30:00 localhost vdr: [7330] TS buffer on device 1 thread ended (pid=7313, tid=7330) Apr 25 18:30:00 localhost vdr: [7329] buffer stats: 5264 (0%) used Apr 25 18:30:00 localhost vdr: [7334] transfer thread started (pid=7313, tid=7334) Apr 25 18:30:00 localhost vdr: [7329] receiver on device 1 thread ended (pid=7313, tid=7329) Apr 25 18:30:00 localhost vdr: [7335] receiver on device 1 thread started (pid=7313, tid=7335) Apr 25 18:30:00 localhost vdr: [7336] TS buffer on device 1 thread started (pid=7313, tid=7336) Apr 25 18:30:00 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 71 10 01 01 13 01 20 14 03 00 83 00 Apr 25 18:30:00 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 70 10 01 01 13 01 20 14 03 03 0B 00 Apr 25 18:30:00 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 72 10 01 01 13 01 20 14 03 02 26 10 Apr 25 18:30:00 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 0F 05 00 F9 6F 10 01 01 13 01 20 14 03 03 28 20 Apr 25 18:30:00 localhost vdr: [7319] CAM: 88C0 212012 8801 0100 1 - 09 89 01 00 F5 8C 33 17 FF 40 00 00 00 08 00 80 44 24 99 F5 88 33 15 FF 00 00 0C 00 00 00 00 06 24 99 F5 8B 33 11 FF 00 00 0E 02 00 00 00 02 24 99 F5 8A A8 21 FF 20 00 01 00 00 00 04 4E 24 99 E5 EC 00 86 FF 00 00 00 Apr 25 18:30:01 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 DF 10 01 01 13 01 20 14 03 00 83 00 Apr 25 18:30:01 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 DD 10 01 01 13 01 20 14 03 03 0B 00 Apr 25 18:30:01 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 E0 10 01 01 13 01 20 14 03 02 26 10 Apr 25 18:30:01 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 0F 05 00 F9 DE 10 01 01 13 01 20 14 03 03 28 20 Apr 25 18:30:01 localhost vdr: [7319] CAM: 88C0 212012 8802 0100 1 - 09 89 01 00 F5 F9 33 17 FF 40 00 00 00 08 00 80 44 24 99 F5 F5 33 15 FF 00 00 0C 00 00 00 00 06 24 99 F5 F4 33 11 FF 00 00 0E 02 00 00 00 02 24 99 F5 F8 A8 21 FF 20 00 01 00 00 00 04 4E 24 99 E6 59 00 86 FF 00 00 00 Apr 25
