Project

General

Profile

Bug #4788

After change PowerVu no anymore descrambling

Added by Petar Ivanov almost 4 years ago. Updated almost 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Descrambling
Target version:
-
Start date:
2017-12-13
Due date:
% Done:

0%

Estimated time:
Found in version:
4.3-777~gc625df2f7
Affected Versions:

Description

After change from last night AFN channels on 9E PowerVU don't descrambling or open one time and freeze.

On enigma2 STB descramblind with oscam in TVH use last oscam + last oscam-emu.


Files

oscam.log (1.06 MB) oscam.log oscam debug level 128 Petar Ivanov, 2017-12-13 02:26
tvh.log (1.55 MB) tvh.log --trace descrambler,capmt Petar Ivanov, 2017-12-13 02:26

History

#1

Updated by Joe User almost 4 years ago

Can't test now because they have switched back to fTA - I guess even offical boxes have problems???

Of interest:
Generated caPMT

2017/12/13 03:11:51 359548D5 c   (dvbapi) PMT Update on socket 14.
2017/12/13 03:11:51 359548D5 c   (dvbapi) Parsing PMT object:
2017/12/13 03:11:51 359548D5 c   (dvbapi)   9F 80 32 82 00 2F 03 00 68 01 00 1F 01 82 02 00 
2017/12/13 03:11:51 359548D5 c   (dvbapi)   01 81 08 00 00 00 00 00 65 00 12 84 02 13 F0 09 
2017/12/13 03:11:51 359548D5 c   (dvbapi)   04 0E 00 17 90 09 04 56 04 0B D8 1B 04 8D 00 00 
2017/12/13 03:11:51 359548D5 c   (dvbapi)   04 04 65 00 00 
2017/12/13 03:11:51 359548D5 c   (dvbapi) capmt:
2017/12/13 03:11:51 359548D5 c   (dvbapi)   03 00 68 01 00 1F 01 82 02 00 01 81 08 00 00 00 
2017/12/13 03:11:51 359548D5 c   (dvbapi)   00 00 65 00 12 84 02 13 F0 09 04 0E 00 17 90 09 
2017/12/13 03:11:51 359548D5 c   (dvbapi)   04 56 04 0B D8 1B 04 8D 00 00 04 04 65 00 00 
2017/12/13 03:11:51 359548D5 c   (dvbapi) Receiver sends PMT command 3 for channel 0068
2017/12/13 03:11:51 359548D5 c   (dvbapi) Receiver wants to demux srvid 0068 on adapter 0001 camask 0002 index 0000 pmtpid 0000
2017/12/13 03:11:51 359548D5 c   (dvbapi) Demuxer 0 try to start new filter for caid: 0001, provid: 000001, pid: 0000
2017/12/13 03:11:51 359548D5 c   (dvbapi) Sending packet to dvbapi client (fd=14):
2017/12/13 03:11:51 359548D5 c   (dvbapi)   40 3C 6F 2B 01 00 00 00 00 00 00 00 00 00 00 00 
2017/12/13 03:11:51 359548D5 c   (dvbapi)   00 00 00 00 00 00 00 00 00 FF 00 00 00 00 00 00 
2017/12/13 03:11:51 359548D5 c   (dvbapi)   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
2017/12/13 03:11:51 359548D5 c   (dvbapi)   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
2017/12/13 03:11:51 359548D5 c   (dvbapi)   04 
2017/12/13 03:11:51 359548D5 c   (dvbapi) Demuxer 0 Filter 1 started successfully (caid 0001 provid 000001 pid 0000)
2017/12/13 03:11:51 359548D5 c   (dvbapi) Demuxer 0 found pmt type: 81 length: 8 (assuming enigma private descriptor: namespace 0000 tsid 65 onid 12)
2017/12/13 03:11:51 359548D5 c   (dvbapi) Demuxer 0 ecmpid 0 CAID: 0E00 ECM_PID: 1790 PROVID: 000000 
2017/12/13 03:11:51 359548D5 c   (dvbapi) Demuxer 0 ecmpid 1 CAID: 5604 ECM_PID: 0BD8 PROVID: 000000 
2017/12/13 03:11:51 359548D5 c   (dvbapi) Demuxer 0 stream Videostream (MPEG-4)(type: 1b pid: 048d length: 0)
2017/12/13 03:11:51 359548D5 c   (dvbapi) Demuxer 0 stream Audiostream (MPEG-2)(type: 04 pid: 0465 length: 0)
2017/12/13 03:11:51 359548D5 c   (dvbapi) Demuxer 0 found 2 ECMpids and 2 STREAMpids in caPMT

Real PMT

2017/12/13 03:11:52 359548D5 c   (dvbapi) pmt:
2017/12/13 03:11:52 359548D5 c   (dvbapi)   02 B0 59 00 68 D1 00 00 E4 8D F0 12 09 04 56 04 
2017/12/13 03:11:52 359548D5 c   (dvbapi)   EB D8 09 04 0E 00 F7 90 0F 04 53 41 50 53 85 E4 
2017/12/13 03:11:52 359548D5 c   (dvbapi)   28 F0 00 04 E4 65 F0 00 1B E4 8D F0 26 28 04 4D 
2017/12/13 03:11:52 359548D5 c   (dvbapi)   40 1E 3F 2A 0F FF 7F 00 00 00 01 00 00 01 C2 00 
2017/12/13 03:11:52 359548D5 c   (dvbapi)   00 03 E9 9F 86 0D E2 65 6E 67 7E 3F FF 65 6E 67 
2017/12/13 03:11:52 359548D5 c   (dvbapi)   C1 3F FF 86 FB C0 F0 00 ED 63 85 07 
2017/12/13 03:11:52 359548D5 c   (dvbapi) Demuxer 0 stream Audiostream (DTS 8)(type: 85 pid: 0428 length: 0)
2017/12/13 03:11:52 359548D5 c   (dvbapi) Demuxer 0 stream Audiostream (MPEG-2)(type: 04 pid: 0465 length: 0)
2017/12/13 03:11:52 359548D5 c   (dvbapi) Demuxer 0 stream Videostream (MPEG-4)(type: 1b pid: 048d length: 38)
2017/12/13 03:11:52 359548D5 c   (dvbapi) Demuxer 0 stream Audiostream (DTS 8 losless)(type: 86 pid: 1bc0 length: 0)
2017/12/13 03:11:52 359548D5 c   (dvbapi) Demuxer 0 found 2 ECMpids and 4 STREAMpids in PMT

One thing I found when I was making my implementation was that Tvheadend only sends the real PMT for the first channel tuned after starting Tvheadend and/or oscam. If I remember correctly, oscam asks for pid 0 (PAT) and from that finds PMT pid and asks for it. But for the second channel, Tvheadend ignores the next request for pid 0 because it is already in the list.

For enigma2, I made a quick hack to oscam to swap the order so the video pid was first, then the audio pid, and it worked. But Tvheadend already does this in the capmt, but it doesn't work???

Unfortunately I did not have time to look at Tvheadend before they switched to FTA...

#2

Updated by Joe User almost 4 years ago

Also of note, they have switched from DES to CSA and the interval has switched to 10sec instead of 1sec.

#3

Updated by Jaroslav Kysela almost 4 years ago

Joe User wrote:

One thing I found when I was making my implementation was that Tvheadend only sends the real PMT for the first channel tuned after starting Tvheadend and/or oscam. If I remember correctly, oscam asks for pid 0 (PAT) and from that finds PMT pid and asks for it. But for the second channel, Tvheadend ignores the next request for pid 0 because it is already in the list.

Could you show me tvh log for this problem? TVH should send data for all filters.

#4

Updated by Joe User almost 4 years ago

Can't do it now, and I am not sure if it is actually a problem. I think I mentioned earlier that I put a test for pid == 0 in capmt.c pid_add to specifically block it. There is a test for PID_UNUSED and first time it matches for pid 0, subsequently it did not. Not sure about your current code. And also not sure of the desired behavior - but should be either always send real PMT or never send. There are advantages/disadvantages for both. The main problems I saw was when I used stream filters to block all but audio track of interest.

#5

Updated by Joe User almost 4 years ago

In pid_remove you test for pid <= 0 so it pid 0 does not get removed (not set to PID_UNUSED)...

capmt_pid_remove(capmt_t *capmt, int adapter, int pid, uint32_t flags)
{
  capmt_adapter_t *ca = &capmt->capmt_adapters[adapter];
  capmt_opaque_t *o;
  mpegts_mux_instance_t *mmi;
  mpegts_mux_t *mux;
  int i = 0, ecm = (flags & CAPMT_MSG_FAST) != 0;

  lock_assert(&capmt->capmt_mutex);

  if (pid <= 0)
    return;
  for (i = 0; i < MAX_PIDS; i++) {
    o = &ca->ca_pids[i];
    if (o->pid == pid && o->ecm == ecm) {
      if (--o->pid_refs == 0)
        break;
      return;
    }
  }
  if (i >= MAX_PIDS)
    return;
  mmi = ca->ca_tuner ? LIST_FIRST(&ca->ca_tuner->mi_mux_active) : NULL;
  mux = mmi ? mmi->mmi_mux : NULL;
  o->pid = PID_BLOCKED;
  o->pid_refs = 0;
  if (o->ecm)
    pid = DESCRAMBLER_ECM_PID(pid);
  o->ecm = -1;
  if (mux) {
    pthread_mutex_unlock(&capmt->capmt_mutex);
    descrambler_close_pid(mux, o, pid);
    pthread_mutex_lock(&capmt->capmt_mutex);
  }
  o->pid = PID_UNUSED;
}

#6

Updated by Joe User almost 4 years ago

I created two bugs associated with this:
[[http://tvheadend.org/issues/4793]]
[[http://tvheadend.org/issues/4794]]
But again I am still not sure if it is good to send the real PMT when filters are being used.

I did a little testing and think there is a timing issue with keys.

I tried setting the interval for 0E00 to 10000 in data/conf/descrambler, but while it may help, it is still slow to start descrambling.

I set "cacheex = 1" in oscam.server for the emu reader and now oscam finds keys from cache and now it works better (no break ups after finally starting) but still slow to start descrambling.
(must have CacheEX support complied in oscam.)
(can also set through webif->readers->oscam-emu->Cache-EX-Mode: 1 - CACHE PULL

Maybe "paritycheck" in data/conf/descrambler also needs to be adjusted???

#7

Updated by Petar Ivanov almost 4 years ago

Yes, after enable webif->readers->oscam-emu->Cache-EX-Mode: 1 - CACHE PULL
AFN start open, but powerVU channels from 4.8 and 1W don't work.

#8

Updated by Joe User almost 4 years ago

Yes, that is a problem. On my enigma2 box (alien2 - sh4) it is working fine without cacheex, so it is possible.

Unfortunately I do not have much time now to work on this. Also, today for some time the audio channels were not encrypted and for some time all pids were using the same cw - so not hardly worth chasing a moving target. Might be best to wait until the provider stops experimenting... Although it is possible that it is not experimenting and actually purposely trying to screw with hackers. :)

#9

Updated by Joe User almost 4 years ago

To overcome the problem of other emu channels not working with cacheex enabled, do the following.

1. Create an oscam.services file with:

[afn]
caid                          = 0E00
provid                        = 000000
srvid                         = 0066,0067,0068,0069,006A,006B,006C,006D

(or add to existing file - making sure "afn" does not already exist...)

2. Create a second emu reader. The oscam.server entries should look something like this simplified example:

[reader]
label                         = oscam_emu
protocol                      = emu
device                        = Emulator
caid                          = 0D00&0F00,090F,0500,1801,0604,0648,0D98,0650,0D95,0E00,1FFF,2600
detect                        = cd
ident                         = 0E00:000000,000002;0D00:000000,000004,000010,000014,000020,0000C0,000000,0000CC;0D02:000000,00008C,0000A0,0000A4,0000A
8;0D03:000000,000004,000008,000024,000028;0D05:000004,000010;090F:000000;0500:030B00,023800,007400,007800;1801:000000;0604:000000;0D98:000000;0650:000
000;0D95:000000
group                         = 1
emmcache                      = 1,5,31,1
emu_auproviders               = 0E00:000000
auprovid                      = 000E00
services                      = !afn

[reader]
label                         = AFN
description                   = AFN-EMU
protocol                      = emu
device                        = Emulator
caid                          = 0E00
detect                        = cd
group                         = 1
emmcache                      = 1,5,31,1
emu_auproviders               = 0E00:000000
auprovid                      = 000E00
cacheex                       = 1
cacheex_maxhop                = 1
cacheex_allow_request         = 1
services                      = afn

The last line for each reader specifies to either use or not use the afn services.
This can also all be done through the webif...

Also available in: Atom PDF