[vdr] Re: CAM Aston 1.05 workaround

[Antonino Sergi <voyaser@tiscalinet.it>]

Hi,

maybe this is a breakthrough:
my system works till step 9 (cams.txt), 9 included, that is "it
decrypts"!

working on the combination vdr-1.2.2/ll-firmware, by using debug
information of DVBTV, as suggested by Miguel, I found that stream_type
is important for Aston/SECA.

Second language is still not accessible (mute), I don't know why.

Here is a rough patch to make it work:
--- vdr-1.2.2/ci.c      2003-08-02 12:00:01.000000000 +0200
+++ vdr-1.2.2-mod/ci.c  2003-09-14 15:16:56.000000000 +0200
@@ -1253,10 +1253,10 @@
   capmt[length++] = 0x00; // program_info_length L
 }

-void cCiCaPmt::AddPid(int Pid)
+void cCiCaPmt::AddPid(int Pid, int StreamType)
 {
   //XXX buffer overflow check???
-  capmt[length++] = 0x00; //XXX stream_type (apparently doesn't matter)
+  capmt[length++] = StreamType; //XXX stream_type (apparently doesn't
matter, except for Aston/SECA)
   capmt[length++] = (Pid >> 8) & 0xFF;
   capmt[length++] =  Pid       & 0xFF;
   esInfoLengthPos = length;

vdr-1.2.2-mod/ci.h
--- vdr-1.2.2/ci.h      2003-05-25 13:44:47.000000000 +0200
+++ vdr-1.2.2-mod/ci.h  2003-09-14 16:51:40.000000000 +0200
@@ -66,7 +66,7 @@
   uint8_t capmt[2048]; ///< XXX is there a specified maximum?
 public:
   cCiCaPmt(int ProgramNumber);
-  void AddPid(int Pid);
+  void AddPid(int Pid, int StreamType);
   void AddCaDescriptor(int Length, uint8_t *Data);
   };

vdr-1.2.2-mod/dvbdevice.c
--- vdr-1.2.2/dvbdevice.c       2003-05-24 15:23:51.000000000 +0200
+++ vdr-1.2.2-mod/dvbdevice.c   2003-09-14 16:52:25.000000000 +0200
@@ -276,13 +276,13 @@
                               cCiCaPmt CaPmt(channel.Sid());
                               CaPmt.AddCaDescriptor(length, buffer);
                               if (channel.Vpid())
-                                 CaPmt.AddPid(channel.Vpid());
+                                 CaPmt.AddPid(channel.Vpid(),0x02);
                               if (channel.Apid1())
-                                 CaPmt.AddPid(channel.Apid1());
+                                 CaPmt.AddPid(channel.Apid1(),0x04);
                               if (channel.Apid2())
-                                 CaPmt.AddPid(channel.Apid2());
+                                 CaPmt.AddPid(channel.Apid2(),0x04);
                               if (channel.Dpid1())
-                                 CaPmt.AddPid(channel.Dpid1());
+                                 CaPmt.AddPid(channel.Dpid1(),0x00);
                               if (ciHandler->SetCaPmt(CaPmt, Slot)) {
                                  tunerStatus = tsCam;
                                  startTime = 0;

On Sun, 2003-08-31 at 13:01, Klaus Schmidinger wrote:
> Antonino Sergi wrote:
> > 
> > On Fri, 2003-08-15 at 16:41, Klaus Schmidinger wrote:
> > > Antonino Sergi wrote:
> > > >
> > > > On Mon, 2003-08-11 at 09:36, Klaus Schmidinger wrote:
> > > > > Antonino Sergi wrote:
> > > > > >
> > > > > > On Sun, 2003-08-10 at 11:06, Klaus Schmidinger wrote:
> > > > > > > Antonino Sergi wrote:
> > > > > > > >
> > > > > > > > I also tried the -icam firmware and, for my setup, it works exactly as
> > > > > > > > any other "NEWSTRUCT" firmware (except ll, of course):
> > > > > > > > it produces "outcommand error" till I make it reveal my CAM (by
> > > > > > > > unplug-plug).
> > > > > > > >
> > > > > > > > Anyway, when it is working, I have no access to second language, as with
> > > > > > > > any other firmware.
> > > > > > > >
> > > > > > > > A new thing:
> > > > > > > > I recorded programs form this channel
> > > > > > > >  Jimmy:11843:V:0:27500:2453:2454:0:1:3560
> > > > > > > > for a year; now I can't see it any more and I do not understand why.
> > > > > > > > I can see any other channel in my bouquet, but not this. I can see it
> > > > > > > > only under windows and, of course, by official decoder; I checked PIDs
> > > > > > > > SID and frequency and they are correct.
> > > > > > > >
> > > > > > > > Is it possible they change something in CA_PMTs only for one channel?
> > > > > > >
> > > > > > > I don't think so.
> > > > > > >
> > > > > > > Please check your chanenls.conf entry for that channel.
> > > > > > > The fourth parameter should tell VDR which satellite this
> > > > > > > channel is on. In your case it is '0', which has no meaning.
> > > > > > >
> > > > > > > Klaus
> > > > > >
> > > > > > This is extracted from channels.conf of vdr-1.0.4, which I use for
> > > > > > production, so that 0 is DiSEqC; the entry is OK, in fact, one that
> > > > > > works is
> > > > > > FOX:11842:V:0:27500:2440:2441:0:1:3550
> > > > > > Sorry to have been not clear, but the problem seems really to exist.
> > > > >
> > > > > Strange... DiSEqC is handled quite differently in VDR 1.2, so you
> > > > > really should try to adapt your channels.conf accordingly.
> > > > >
> > > > > Klaus
> > > >
> > > > Now they changed PIDs for that channel and it works again; I noticed
> > > > that they change PIDs frequently now. Could it be a way to "fight"
> > > > unofficial decoders? (like VDR?)
> > >
> > > Well, maybe, maybe not.
> > > You may want to try the autopid patch (from Andreas Schultz) if you
> > > often watch channels that frequently change PIDs.
> > >
> > I'll try
> > > > I'll keep trying to understand why vdr-1.2 and ll-firmware is not able
> > > > to decrypt.
> > >
> > > You're confusing me - didn't you just write "Now they changed PIDs for that
> > > channel and it works again"? You need to be a lot more clear about _exactly_
> > > what you are experiencing with which version of the driver and/or VDR.
> > >
> > > Klaus
> > Ok, you are right.
> > 
> > Situation update:
> > 
> > RedHat9
> > kernel-2.4.18-14 (RH8)
> > Nexus rev 2.1
> > CI rev 1.6 (3.5") (set to 3.3V)
> > CAM Aston 1.05
> > 
> > Migrated to vdr-1.2.2 with -icam firmware from cvs (05th Aug 2003)
> > Aug 17 13:46:59 desktop kernel: DVB: registering new adapter
> > (Technotrend/Hauppauge PCI rev2.1 or 2.2).
> > Aug 17 13:46:59 desktop kernel: PCI: Found IRQ 11 for device 00:09.0
> > Aug 17 13:46:59 desktop kernel: stv0299.c: setup for tuner BSRU6,
> > TDQB-S00x
> > Aug 17 13:46:59 desktop kernel: DVB: registering frontend 0:0
> > (STV0299/TSA5059/SL1935 based)...
> > Aug 17 13:47:03 desktop kernel: DVB: AV7111(0) - firm f0240009, rtsl
> > b0250018, vid 71010068, app 0000261a
> > Aug 17 13:47:03 desktop kernel: DVB: AV7111(0) - no firmware support for
> > CI link layer interface
> > Aug 17 13:47:03 desktop kernel: av7110(0): Crystal audio DAC detected
> > Aug 17 13:47:03 desktop kernel: Technotrend/Hauppauge PCI rev2.1 or 2.2
> > adapter 0 has MAC addr = 00:d0:5c:20:c5:
> > 5c
> > Aug 17 13:47:03 desktop runvdr: Verifying CAM detection...
> > Aug 17 13:47:06 desktop kernel: av7111(0): 01 01 01 00 00 00 00 00 00 00
> > 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 00 00 00 00 00 00 00 00 00
> > Aug 17 13:47:14 desktop kernel: av7111(0): 01 02 01 00 41 53 54 4f 4e 00
> > 00   ASTON
> > Aug 17 13:47:17 desktop kernel: av7111(0): 0e 04 30 00 41 53 0 AS
> > 
> > It works exactly (about CAM) like vdr-1.0.4 driver 0.9.4 (cvs 26th Aug
> > 2002):
> > 
> > Cam is detected automatically only if CI-CAM temperature is under 25°C,
> > otherwise it needs unplug-plug by hands;
> > After any of this two operations, I can reload modules any number of
> > times and it is detected without unplug-plug.
> > I have no access to second language.
> > If replay a recording (recorded from an encrypted channel), replay speed
> > is accelerated by about a factor 2 (audio included), while mplayer
> > (plugin and standalone) replays it correctly;
> > If I replay a recording when tuned to an encrypted channel I hear
> > corrupted audio, while mplayer (plugin and standalone) replays it
> > correctly;
> > 
> > What I'm testing:
> > using vdr-1.2.2 with LL firmware (same cvs as above), according cams.txt
> > prescriptions everything works except step 9 (decrypting); maybe you
> > want to update cams.txt.
> > I want to stress the fact that here my CAM is detected by vdr every time
> > in any condition (could -icam firmware learn it from vdr?).
> > 
> > I'm trying to understand why step 9 is not working
> > 
> > I hope to have been clear
> 
> You may want to try he patch Hans-Peter Raschke has posted in 
> http://linuxtv.org/mailinglists/vdr/2003/08-2003/msg01056.html.
> He claimed that this made the SkyCrypt-CAM work in his system,
> maybe it also influences the Aston CAM.
> 
> Klaus
-- 
Antonino Sergi <voyaser@tiscalinet.it>
Evolution Enterprises



-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.