VIACCESS DVBAPI TCP no EMM Updates (filter issue?) CAID 0500

[hauvol]

Revision

r11314

Issue Description

EMMs for Viaccess CAID 1843 (V5.0) no written to card (filtered by OSCAM)

When the issue occurs

EMM Update

How the issue is reproducable

on EMM Update, see ​https://tvheadend.org/issues/4141#change-20695

[hauvol]

TVHEADEND LOG

[hauvol]

OSCAM LOG

[hauvol]

Sorry caid is 0500 provid 050800

[pr2]

This ticket is probably a duplicate of this one and is probably not specific to Viaccess.

http://www.streamboard.tv/oscam/ticket/4354

[hauvol]

Jaroslav Kysela did analyze this for me (tvheadend.org):
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

[pr2]

You should be really happy that Viaccess with CAID: 1843 doesn't receive EMMs!
CAID for Viaccess is always 0500
1843 is Nagra

Please edit the description to reflect the real problem.

[hauvol]

please see comment 1. I mentioned 1843 by mistake. please reopen , it's related to caid 0500.

[pr2]

Why do you mention that the bug is on the OScam side???

That's TVH that handle the "dvbapi" side and the interaction with the card. The ticket on the TVH site that you point to is this:

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.

So in other words the bug is on SAT>IP side and this one is handled by TVH and not by OScam.

For Viaccess you need to have somewhere EMM reassembly done, so either on the client side (TVH) or on the Server side (OScam).
If you wrongly configure it then it won't work. If you enable EMM reassembly on both side this won't work either.

But anyway you mention that this is working with PCI Express! So clearly the problem is on the TVH side since it should make no difference between PCIE or SAT>IP on the pure OScam side, since the connection method is the same with your TVH.

So the link between OScam and TVH is always the same, same setup, same parameter so TVH is the abstraction layer for OScam.
If TVH work properly with PCIE tuner and not with SAT>IP you cannot blame OScam.

Debugging should be done on TVH side.
Compare log on TVH when you use PCIE tuner and when you use SAT>IP and you will find where the problem is.
Perhaps that SAT>IP doesn't support all the EMM filters properly or that the number of possible filters are limited in SAT>IP.
Are you sure that SAT>IP is fully capable to transport EMM?
Since EMM are splitted into several pieces are you sure that SAT>IP support this?

So clearly this ticket is invalid and incomplete (we need to read a TVH bug report to understand what the problem is!).
The problem is not on the OScam side, it is TVH that send the EMM to OScam. OScam has no direct access to your SAT>IP and the problem occurs in this case!

[hauvol]

The main difference between using oscam with camd.socket is that tvheadend writes all emms to camd.socket and oscam takes the emms which matches. using tvheadend with dvbapi in tcp mode, oscam pushes the filter to tvheadend so tvheadend only sends the emms which oscam wants.

That's what I understood from Jaroslav's analysis.

So my question is regarding the filters oscam uses / sets in dvbapi tcp mode. May these be different from the filters oscam applies using camd.socket?

[pr2]

The way to communicate between OScam and TVH is through dvbapi in TCP mode and this is working you report it yourself!
So use the correct mode and don't try to use non supported features. Why do you want to use camd socket if they doesn't work properly.
On my STB with OScam running I also have many "dvbapi" possibilities and I need to choose the one that work best and some doesn't work at all and that's normal.