Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] Re: CAM Aston 1.05 workaround
Hi Patrick,
I don't understand. I tried to change channel settings to have only one
language (the second one), but I can't hear anything.
Did I misunderstood your solution?
Thanks
On Tue, 2003-09-16 at 22:41, Patrick Gueneau wrote:
> Hi Antonio,
>
> I Would like to thank you for this great effort !!
>
> ASTON CAM is NOW working on my setup (DVB-S Rev 1.3 / Kernel 2.4.21)
> with Canal+/CanalSat SECA2 Card.
>
> I have just patched/modified vdr 1.2.1 using your mods.
> It is working using standard DVB-1.0.
>
> Concerning Second language, it may be necessary to add only one
> AudioPid and change it when toggling Audio track.
> I have done a test registering only the second AudioPid
> (cCiCaPmt::AddPid). As expected, I can here second language track when
> toggling track using Main Menu green button.
>
> That means we need to setup a new CA Descriptor and call SetCaPmt after
> Audio Toggle.
>
> It is the way my setup is working ATM using a modified DVB driver using
> TT firmware and VDR 1.04 :
>
> Only one Audio Track at the same time / Only one track recorded
>
>
> Thanks Again Antonino.
>
>
> Patrick.
>
> Le lundi, 15 sep 2003, à 08:52 Europe/Paris, Antonino Sergi a écrit :
>
> > 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.
> >
--
Antonino Sergi <voyaser@tiscalinet.it>
Evolution Enterprises
--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.
Home |
Main Index |
Thread Index