[vdr] Re: CAM Aston 1.05 workaround

[Antonino Sergi <voyaser@tiscalinet.it>]

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

Thanks

-- 
Antonino Sergi <voyaser@tiscalinet.it>



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