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:Now they changed PIDs for that channel and it works again; I noticedAntonino Sergi wrote:On Sun, 2003-08-10 at 11:06, Klaus Schmidinger wrote:This is extracted from channels.conf of vdr-1.0.4, which I use forAntonino 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
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
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 tryOk, you are right.I'll keep trying to understand why vdr-1.2 and ll-firmware is not ableYou're confusing me - didn't you just write "Now they changed PIDs for that
to decrypt.
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
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.
-- Info: To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.