Project

General

Profile

Bug #2262

Fails to show scrambled channels

Added by Andreas Lunderhage about 10 years ago. Updated about 10 years ago.

Status:
Need feedback
Priority:
Normal
Assignee:
-
Category:
Descrambling
Target version:
-
Start date:
2014-08-29
Due date:
% Done:

0%

Estimated time:
Found in version:
3.9.1357~g4ce05e5
Affected Versions:

Description

I have a problem with cwc not working.

If I start watch a scrambled channel, the stream appears to start (shows up in status).
TVHeadend seems to send OK ecms to OSCam which is responding. But nothing more happens!

Watching freeview channels work fine.

Signal seems OK:
lunderhage@LunTV:~$ tzap -a 0 -c channels.conf "Discovery Channel"
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file 'channels.conf'
Version: 5.10 FE_CAN { DVB-T + DVB-T2 + DVB-C (A) }
tuning to 706000000 Hz
video pid 0x03ab, audio pid 0x03aa
status 1f | signal ffff | snr 0057 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ffff | snr 00de | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ffff | snr 00e5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ffff | snr 00e0 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ffff | snr 00e3 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ffff | snr 00e1 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ffff | snr 00e4 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ffff | snr 00e3 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ffff | snr 00e1 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ffff | snr 00e2 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ffff | snr 00e3 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ffff | snr 00e1 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal ffff | snr 00e1 | ber 00000000 | unc 00000000 | FE_HAS_LOCK

I'm running TVHeadend on an Ubuntu 14.04 x64 box using dual pctv 290e dongles.


Files

tvheadend.log (13.3 KB) tvheadend.log Some logs Andreas Lunderhage, 2014-08-29 22:33
tvheadend.log (13.8 KB) tvheadend.log Testing some scrambled and not scrambled channels Andreas Lunderhage, 2014-09-09 13:16
tvheadend2.log (208 KB) tvheadend2.log Andreas Lunderhage, 2014-09-09 21:12
tvheadend3.log (78 KB) tvheadend3.log Andreas Lunderhage, 2014-09-09 21:18
tvheadend4.log.tar.bz2 (7.79 MB) tvheadend4.log.tar.bz2 --trace all Andreas Lunderhage, 2014-09-09 21:43
TV3 STOCKHOLM.png (111 KB) TV3 STOCKHOLM.png Service info dialog for TV3 STOCKHOLM Andreas Lunderhage, 2014-09-10 21:04
Screenshot_2014-09-11-21-21-27.png (136 KB) Screenshot_2014-09-11-21-21-27.png Andreas Lunderhage, 2014-09-11 21:24
ProgDVB_Discovery.jpg (175 KB) ProgDVB_Discovery.jpg Example Andreas Lunderhage, 2014-09-20 00:10
OSCam_TVHeadend_Discovery_Channel.txt (27.8 KB) OSCam_TVHeadend_Discovery_Channel.txt Andreas Lunderhage, 2014-09-20 12:13
OSCam_ProgDVB_Discovery_Channel.txt (19.1 KB) OSCam_ProgDVB_Discovery_Channel.txt Andreas Lunderhage, 2014-09-20 12:13
tvheadend_patch1.log (25.6 KB) tvheadend_patch1.log Andreas Lunderhage, 2014-09-21 11:41
oscam_capmt.log (7.17 KB) oscam_capmt.log Andreas Lunderhage, 2014-09-21 20:24
tvheadend_patch1_capmt.log (53.5 KB) tvheadend_patch1_capmt.log Andreas Lunderhage, 2014-09-21 20:25
tvheadend_patch2.log (16.6 KB) tvheadend_patch2.log Andreas Lunderhage, 2014-09-23 21:34
progdvb+tvheadend_kanal5.txt (42.9 KB) progdvb+tvheadend_kanal5.txt Andreas Lunderhage, 2014-09-27 12:44

History

#1

Updated by Andreas Lunderhage about 10 years ago

BTW: OSCAM: 1.20-unstable_svn Build: r9827 Compiler: x86_64-linux-gnu-ssl

#2

Updated by Jaroslav Kysela about 10 years ago

Please, enable cwc and descrambler trace (--trace cwc,descrambler).

#3

Updated by Jaroslav Kysela about 10 years ago

  • Status changed from New to Need feedback
#4

Updated by Andreas Lunderhage about 10 years ago

Here is a log with traces.

"TV 4 Stockholm" and "TV6" are not scrambled. Works fine, no reception problems.

"Kanal 11" and "CNN" are on the same mux and are scrambled. Nothing seem to happen.

#5

Updated by Andreas Lunderhage about 10 years ago

Some better logs here.

#6

Updated by Andreas Lunderhage about 10 years ago

It looks like cwc itself works (refreshes the key periodically). HTTP server does not respond at all though... Let's dig into that...

#7

Updated by Andreas Lunderhage about 10 years ago

Here is a log with --trace all.

BTW: Version of today is 3.9.1429~gea60d88.

#8

Updated by Jaroslav Kysela about 10 years ago

Could you show me the service info dialog for the "V3 STOCKHOLM" ?

#9

Updated by Jaroslav Kysela about 10 years ago

Jaroslav Kysela wrote:

Could you show me the service info dialog for the "V3 STOCKHOLM" ?

TV3 STOCKHOLM ...

#11

Updated by Jaroslav Kysela about 10 years ago

I meant the info in the dialog which appears when you click on the "i" icon on left in the service row..

#13

Updated by Jaroslav Kysela about 10 years ago

It looks all ok. The descrambling works without any error messages and I don't see anything suspicious. Could you try to set the "pass-through" in the default DVR config and try another player (vlc, mplayer) directly (just copy the link for a service or channel from the "Play" column)...

#14

Updated by Andreas Lunderhage about 10 years ago

Something happens at least with pass-through:

lunderhage@LunTV:/home/share/test$ wget http://luntv:9981/play/stream/service/34b869a774d2b2adf1cb0ac2cbd9c96e?title=TV3%20STOCKHOLM%20%2F%20Viasat%20AB
--2014-09-12 20:18:22-- http://luntv:9981/play/stream/service/34b869a774d2b2adf1cb0ac2cbd9c96e?title=TV3%20STOCKHOLM%20%2F%20Viasat%20AB
Resolving luntv (luntv)... 127.0.1.1
Connecting to luntv (luntv)|127.0.1.1|:9981... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [video/x-mpegts]
Saving to: ‘34b869a774d2b2adf1cb0ac2cbd9c96e?title=TV3%20STOCKHOLM%20%2F%20Viasat%20AB’

[                           <=>         ] 36,160,592   335KB/s             ^C

But can't play it.

VLC is complaining about:
ts warning: invalid header [0x06:d2:26:e8] (pid: 3009)
ts warning: invalid header [0x0f:cd:67:0c] (pid: 3009)
ts warning: invalid header [0xe9:cf:f2:19] (pid: 3009)
ts warning: invalid header [0xe4:a2:6c:a9] (pid: 3009)
ts warning: invalid header [0x68:1a:6c:85] (pid: 3008)
ts warning: invalid header [0x0d:d5:ba:14] (pid: 3009)
ts warning: invalid header [0xca:df:bb:14] (pid: 3009)
ts warning: invalid header [0x6d:6f:74:bb] (pid: 3009)
ts warning: invalid header [0x76:ec:e9:f3] (pid: 3009)
ts warning: invalid header [0x4a:66:e3:05] (pid: 3008)
ts warning: invalid header [0xef:f6:9e:99] (pid: 3009)

Freeview channels work though (but kind of laggy).

#15

Updated by Crazy Fin about 10 years ago

I am on OSCAM r9847 together with TVH 3.9.1447 and Ubuntu 14.04. I watch Canal Digital Nordic channels also but via the Telenor THOR 0.8W satellite.

I had similar problems until I turned off "Network Discovery" and "Idle Scan Muxes" in TVH.

Was your scrambled channels working ok before or has it always been a problem?

#16

Updated by Andreas Lunderhage about 10 years ago

Turning of "Network Discovery" and "Idle Scan Muxes" does not do any difference for me.

#17

Updated by Andreas Lunderhage about 10 years ago

I tried commmit 4bce3dc4aeda9b5c6338c09bcd07d35accc94983 today. Still same problem.

Is there anything else I can help out with?

#18

Updated by Jaroslav Kysela about 10 years ago

Do you have any other device using oscam ? Does it work ? It looks like that the keys from oscam are invalid..

#19

Updated by Andreas Lunderhage about 10 years ago

The scrambled Discovery Channel works fine in ProgDVB in Windows. Alex interface as well. So no problems with OSCam.

#20

Updated by Jaroslav Kysela about 10 years ago

Could you gather logs from oscam for ProgDVB and tvheadend for one channel to compare?

#22

Updated by Jaroslav Kysela about 10 years ago

Could you try this change in the code?

diff --git a/src/descrambler/descrambler.c b/src/descrambler/descrambler.c
index cfce636..778d410 100755
--- a/src/descrambler/descrambler.c
+++ b/src/descrambler/descrambler.c
@@ -208,7 +208,7 @@ descrambler_keys ( th_descrambler_t *td, int type,
     }

   for (i = 0; i < csa->csa_keylen; i++)
-    if (even[i]) {
+    if (even[i] && (dr->dr_key_index == 0xff || (dr->dr_key_index & 0x40) != 0)) {
       j++;
       tvhcsa_set_key_even(csa, even);
       dr->dr_key_valid |= 0x40;
@@ -216,7 +216,7 @@ descrambler_keys ( th_descrambler_t *td, int type,
       break;
     }
   for (i = 0; i < csa->csa_keylen; i++)
-    if (odd[i]) {
+    if (odd[i] && (dr->dr_key_index == 0xff || (dr->dr_key_index & 0x40) == 0)) {
       j++;
       tvhcsa_set_key_odd(csa, odd);
       dr->dr_key_valid |= 0x80;
#23

Updated by Andreas Lunderhage about 10 years ago

I updated to commit a8d5bbc067155f6394162c68a17f496ddf65237e and applied the patch. No difference.

#24

Updated by Jaroslav Kysela about 10 years ago

OK, another idea - could you try to use the 'capmt' client rather than cccam ? The oscam handles more key logic itself in this case, and perhaps, something special is required for you CAS.

#25

Updated by Jaroslav Kysela about 10 years ago

Also, don't forget to include the descramber to the trace, like 'descrambler,capmt,cwc' ..

#27

Updated by Jaroslav Kysela about 10 years ago

I assume that it does not work. I'm getting out of ideas. Everything seems good, but used keys are not valid (thus the descrambled packets are not valid). Note that other 0500 CAID cards works without any issues.

Probably ProgDVB does something with keys before they are used..

Looking to oscam sources, the even / odd keys might be swapped..

diff --git a/src/descrambler/descrambler.c b/src/descrambler/descrambler.c
index cfce636..feaa11a 100755
--- a/src/descrambler/descrambler.c
+++ b/src/descrambler/descrambler.c
@@ -207,8 +207,10 @@ descrambler_keys ( th_descrambler_t *td, int type,
       goto fin;
     }

+  { const uint8_t *tmp = even; even = odd; odd = tmp; }
+
   for (i = 0; i < csa->csa_keylen; i++)
-    if (even[i]) {
+    if (even[i] && (dr->dr_key_index == 0xff || (dr->dr_key_index & 0x40) != 0)) {
       j++;
       tvhcsa_set_key_even(csa, even);
       dr->dr_key_valid |= 0x40;
@@ -216,7 +218,7 @@ descrambler_keys ( th_descrambler_t *td, int type,
       break;
     }
   for (i = 0; i < csa->csa_keylen; i++)
-    if (odd[i]) {
+    if (odd[i] && (dr->dr_key_index == 0xff || (dr->dr_key_index & 0x40) == 0)) {
       j++;
       tvhcsa_set_key_odd(csa, odd);
       dr->dr_key_valid |= 0x80;

Could you use your card with any other open source program (to check sources) ?

#28

Updated by Andreas Lunderhage about 10 years ago

Are there any suggestions for other open source programs? The only one I have used is TVHeadend.

#30

Updated by Andreas Lunderhage about 10 years ago

I have set up MumuDVB, but for some reason scrambled channels work even without me having configuring the oscam part. I think they are showing all channels for free today.

#31

Updated by Andreas Lunderhage about 10 years ago

I made some mistake with that patch. Here is a new log with the patch applied.

#32

Updated by Andreas Lunderhage about 10 years ago

I have tried MumuDVB, but it is only crashing on me when trying to request for keys.

Some conclusions can be made: In the OSCam end, both client are requesting the same keys at the same time (one gets it from the cache).

ProgDVB can descramble fine.
TVHeadend: descrambler: cannot decode packets for service "Kanal 5 Stockholm"

I have some faint memory about my subscription card has multiple provider id:s, where I have to explicitly have to choose the right ones.

ACamd configuration (ProgDVB):

cardclient.conf:
newcamd:192.168.10.2:15000:1/0500/ffff:lunderhage:********:0000000000000000000000000000

ACamd_PMT.txt:
  1. Preferred
    P:0500:00023208:caid
    P:0500:00040D00:caid

Since it did work once upon a time, I will start digging into the git history.

BTW: There will of course be a reward if this problem is finally fixed! :-)

Also available in: Atom PDF