Tvheadend

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...

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

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.

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.

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;
}

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???

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.

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.

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

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...

I have the exact same problem with the newest version of tvheadend and oscam. Enabling cachex is not working unfortunately. Is there another solution available?