Project

General

Profile

Feature #4141

Viaccess Emms via SAT>IP Receiver

Added by Ted X almost 8 years ago. Updated almost 8 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
SAT>IP
Target version:
-
Start date:
2016-12-18
Due date:
% Done:

0%

Estimated time:

Description

It seems like tvheadend doesn't forward viaccess v5.0 (SRF) emms to oscam.

This issue only occurs if a sat>ip receiver is used. Emms are forwarded correctly if pciexpress tuners are used. This issue occurs with tvheadend 3.9 too.

I'm currently using tvh version 4.1-2389~gf49ea87, oscam r11289.


Files

nonworking.zip (122 KB) nonworking.zip Ted X, 2016-12-27 10:36
OSCAM_TVHEADEND_LOG.zip (43.6 KB) OSCAM_TVHEADEND_LOG.zip Ted X, 2017-01-07 09:46
OSCAM_TVHEADEND_LOG_v4.1-2410-g9ad9427.zip (1.11 MB) OSCAM_TVHEADEND_LOG_v4.1-2410-g9ad9427.zip Ted X, 2017-01-07 22:10

History

#1

Updated by Jaroslav Kysela almost 8 years ago

There should not be a difference between SAT>IP and Linux (DVBAPI) tuners for this. Provide logs for '--trace descrambler,capmt' for the working and non-working cases. https://tvheadend.org/projects/tvheadend/wiki/Traces

#2

Updated by Ted X almost 8 years ago

Jaroslav Kysela wrote:

There should not be a difference between SAT>IP and Linux (DVBAPI) tuners for this. Provide logs for '--trace descrambler,capmt' for the working and non-working cases. https://tvheadend.org/projects/tvheadend/wiki/Traces

attached you can find the non working log. I'll post the working one later this day.

#3

Updated by Ted X almost 8 years ago

So finally I found the issue:
I'm able to update emms via camd.socket and oscam r11289 only.

This is only possible with physical adapters:
"capmt: tvheadend: Virtual adapters are supported only in modes 3, 4, 5 and 6 (service "SIXX HD")"

Is there any option to use capmt with sat>ip adapters?

#4

Updated by Jaroslav Kysela almost 8 years ago

It seems like an oscam bug. You are already using the network mode for the dvbapi module in your non-working example.

2016-12-27 10:22:22.480 [   INFO]:subscription: AC96: "HTTP" subscribing on channel "SRF 1 HD", weight: 100, adapter: "SAT>IP DVB-S Tuner #3 (172.17.200.21)", network: "Hotbird 13.0", mux: "10971.41H", provider: "Schweizer Radio und Fernsehen", service: "SRF 1 HD", profile="pass", hostname="172.17.1.187", username="xxx", client="VLC/3.0.0-git LibVLC/3.0.0-git" 
2016-12-27 10:22:22.998 [  DEBUG]:tbl-base: cat:  caid 0500 (1280) pid 025D (605)
2016-12-27 10:22:22.998 [  DEBUG]:tbl-base: cat:  caid 0500 (1280) pid 025A (602)
2016-12-27 10:22:22.998 [  DEBUG]:tbl-base: cat:  caid 0500 (1280) pid 025B (603)
2016-12-27 10:22:22.998 [  DEBUG]:tbl-base: cat:  caid 0500 (1280) pid 025C (604)
2016-12-27 10:22:45.237 [  TRACE]:descrambler: EMM message 8e:70:2c:c4 (len 47, pid 604)
2016-12-27 10:22:45.237 [  TRACE]:capmt: filter match pid 604 len 47 emm 1
2016-12-27 10:22:57.421 [  TRACE]:descrambler: EMM message 8e:70:2c:c4 (len 47, pid 604)
2016-12-27 10:22:57.437 [  TRACE]:capmt: filter match pid 739 len 42 emm 0

So some EMMs are passed, but most of them are just ignored. The filters are set by oscam, so there are two possibilities:

1) filters are wrong - blame oscam
2) filters are good - there's something wrong in the filter processing on the tvheadend side

EMMs seems to be received fine (but ignored by the capmt filter):

2016-12-27 10:23:14.348 [  TRACE]:descrambler: EMM message 8e:70:2c:c4 (len 47, pid 604)
2016-12-27 10:23:14.348 [  TRACE]:descrambler: EMM message 8e:70:2c:c4 (len 47, pid 604)
2016-12-27 10:23:14.348 [  TRACE]:descrambler: EMM message 8e:70:2c:c4 (len 47, pid 604)
2016-12-27 10:23:14.455 [  TRACE]:descrambler: EMM message 8e:70:2c:c4 (len 47, pid 604)
2016-12-27 10:23:14.490 [  TRACE]:descrambler: EMM message 88:70:b4:00 (len 183, pid 604)
2016-12-27 10:23:14.982 [  TRACE]:descrambler: EMM message 8d:70:0c:90 (len 15, pid 604)
2016-12-27 10:23:15.000 [  TRACE]:descrambler: EMM message 88:70:b4:00 (len 183, pid 604)
2016-12-27 10:23:15.088 [  TRACE]:descrambler: EMM message 8e:70:2c:c4 (len 47, pid 604)
2016-12-27 10:23:15.088 [  TRACE]:descrambler: EMM message 8e:70:2c:c4 (len 47, pid 604)
2016-12-27 10:23:15.088 [  TRACE]:descrambler: EMM message 8e:70:2c:c4 (len 47, pid 604)
2016-12-27 10:23:15.088 [  TRACE]:descrambler: EMM message 8e:70:2c:c4 (len 47, pid 604)
2016-12-27 10:23:15.088 [  TRACE]:descrambler: EMM message 8e:70:2c:c4 (len 47, pid 604)

For old oscam / capmt modes - there is no filtering on the client side - all EMM data are sent to the oscam unfiltered.

Could you provide both tvheadend log (like before) and oscam debug log (option 128) when you tune one channel on the transpoder (mux) with the EMM data?

#5

Updated by Ted X almost 8 years ago

Attached you can find the requested logs.

#6

Updated by Jaroslav Kysela almost 8 years ago

Could you uprade to v4.1-2410-g9ad9427 and provide again the tvheadend log? I need to dump more EMM data for skipped EMMs. The oscam log is fine. Also, please, tune to the same channel (SRF zwei HD).

#8

Updated by Jaroslav Kysela almost 8 years ago

All filters set by oscam:

FILTER DUMP: filter=0, pid=604
  data : 8c000000080000000000000000000000
  mask : fe000000fff000000000000000000000
FILTER DUMP: filter=2, pid=604
  data : 8ec434e7000000000000000000000000
  mask : ffffffff000000000000000000000000
FILTER DUMP: filter=3, pid=604
  data : 8c000000081000000000000000000000
  mask : fe000000fff000000000000000000000
FILTER DUMP: filter=4, pid=604
  data : 8c000000082000000000000000000000
  mask : fe000000fff000000000000000000000
FILTER DUMP: filter=5, pid=604
  data : 8c000000083000000000000000000000
  mask : fe000000fff000000000000000000000
FILTER DUMP: filter=6, pid=604
  data : 8c000000084000000000000000000000
  mask : fe000000fff000000000000000000000
FILTER DUMP: filter=7, pid=604
  data : 8a000000080000000000000000000000
  mask : fe000000fff000000000000000000000
FILTER DUMP: filter=8, pid=604
  data : 8a000000081000000000000000000000
  mask : fe000000fff000000000000000000000
FILTER DUMP: filter=9, pid=604
  data : 8a000000082000000000000000000000
  mask : fe000000fff000000000000000000000
FILTER DUMP: filter=10, pid=604
  data : 8a000000083000000000000000000000
  mask : fe000000fff000000000000000000000
FILTER DUMP: filter=11, pid=604
  data : 8a000000084000000000000000000000
  mask : fe000000fff000000000000000000000
FILTER DUMP: filter=12, pid=604
  data : 88c434e7260000000000000000000000
  mask : ffffffffff0000000000000000000000
FILTER DUMP: filter=1, pid=739
  data : 80000000000008e20000000000000000
  mask : ff0000000000ffff0000000000000000

TVH matches only this one (filter 2):

2017-01-07 21:59:42.801 [ TRACE]:capmt: filter match pid 604 len 47 emm 1
2017-01-07 21:59:42.801 [ TRACE]:descrambler: EMM message 8e:{70:2c}:c4:34:e7:00:ff:ff:ff:f7:7f:ff:ff:ff:ff:ff:ff (len 47, pid 604)

The bytes in {} are skipped, the filter specify value and the data mask for 0,3,4,5,6,7,8,10,11,12,13,14,15,16,17-th byte in the EMM message, if you like to check it yourself. I created a python script to analyze this from the logs https://github.com/tvheadend/tvheadend/blob/master/support/emm.py .

I would suggest to provide all lines with 'EMM message' and 'pid 604' from tvh and oscam logs to the oscam developers to fix the EMM handling in the oscam, if you believe that it's really an error.

OSCAM issue tracker: http://www.streamboard.tv/oscam/report

#9

Updated by Ted X almost 8 years ago

Thanks for your work Jaroslav. can you confirm I have to use emmreasembly=1 in oscam.user? Is this option needed with dvbapi in tcp mode?

Best Regards
Ted

Also available in: Atom PDF