[vdr] Re: CAM Aston 1.05 workaround

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

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


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