Bug #4788
open
After change PowerVu no anymore descrambling
Added by Petar Ivanov over 7 years ago. Updated almost 2 years ago.
0%
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
Updated by Joe User over 7 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...
Updated by Joe User over 7 years ago
Also of note, they have switched from DES to CSA and the interval has switched to 10sec instead of 1sec.
Updated by Jaroslav Kysela over 7 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.
Updated by Joe User over 7 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.
Updated by Joe User over 7 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;
}
Updated by Joe User over 7 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???
Updated by Petar Ivanov over 7 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.
Updated by Joe User over 7 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. :)
Updated by Joe User over 7 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...
Updated by Thomas Bartl almost 2 years ago
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?