Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: CAM Aston 1.05 workaround

Ok, I will try to be more precise.

When I use VDR v1.0.4 and Patched DVB Driver I can switch from 1 language to the second one but I can't record 2 audio Pids at the same time.
It seems to be a drawback/limit of SECA encryption. Actually I have modified VDR source to disable second audio pid filtering.

Based on you patch, I made a test to have only one Audio Pid and choose to set the second one (Apid2) in Ca Descriptor:

- at first, no sound can be heard
- after switching to second audio using green button, I was able to hear 'English' audio track.
I made this test to be sure Audio Pids was not 'hardcoded' by Program Id (as it used to be with Convergence Firmware and SECA1 programs).


As Apid1 is working all the time, It seems to prove that you can only put one audio pid in CA Descriptor.
I haven' t look at VDR CI/CAM handling code (I am still using old VDR 1.0.4) but it seems you need to call SetCaPMT with the right Audio PIDs before/after (?) each audio Toggle.


I hope it is a bit more clear now ;-)

Patrick.

Le mercredi, 17 sep 2003, à 09:37 Europe/Paris, Antonino Sergi a écrit :

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.



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.
Home | Main Index | Thread Index