Tvheadend

Hello TVH and DD CI users!

I have implemented MCD (Multi Channel Decoding), the second step, to the DD CI code.
There is currently no MTD (Multi Tuner Decoding) implemented.

I tested this with my ORF card in an Alphacrypt CAM with "ORF1 HD", "ORF2W HD" and "ServusTV HD Oesterreich" (these are all on the same transponder).
Please note, that you have to activate "CAM can decode multi channels" and set the "Service limit" to the number of channels your CAM can decode (3 or 4 is a good value for the Alphacrypt CAM) in the CA configuration.

You can find the code at GitHub on the ddci_mcd branch:

https://github.com/jasmin-j/tvheadend/tree/ddci_mcd

Configure it with the new option "--enable-ddci_mcd".
I will submit a pull request when some people did test this. Please write your experience here or send me an eMail.

Have fun and BR,
Jasmin

Hello Jasmin,

I hope you had a nice vacation

On my setup your MCD implementation looks good! I was able to decode two Sky channels at the same time (on the same transponder).

My previous problem using OSCam and DDCI at the same time, still exists...
I didn't find any settings in the ACL to configure the "announcement" of supported CAIDs...

Hello Alexander!

On my setup your MCD implementation looks good! I was able to decode two Sky channels at the same time (on the same transponder).

Perfect! THX for testing this. I will change the commits on the branch and then do the PR.

I didn't find any settings in the ACL to configure the "announcement" of supported CAIDs...

First of all, I have an AlphaCrypt 3.27 from Mascom and not the ACL. So maybe the ACL doesn't support such a setting.
My CAM reports:

  CAM INFO: AlphaCrypt, 01, 4A20, 4A20

On my CAM it is in the Expert Menue:

   CA-Systems: Single
   dbox Compatibility: on

My previous problem using OSCam and DDCI at the same time, still exists...

As I wrote already I don't understand why. When the HW CAM is used completely (limit set to 1), TVH should select automatically the next descrambler which can decode the stream. And this can be a SW CAM also.

My CAM is also announcing all CAIDs:

CAM supported CAIDs: 0D95 (CryptoWorks ICE) 0648 (Irdeto) 1702 (BetaCrypt) 1722 (BetaCrypt)
CAM supported CAIDs: 1762 (BetaCrypt) 4A20 (0x4a20) 0500 (Viaccess) 0B00 (Conax)
CAM supported CAIDs: 0100 (Seca) 1833 (NagraVision) 1834 (NagraVision) 0D05 (CryptoWorks)
CAM supported CAIDs: 0D22 (CryptoWorks)
caids_count 13

I do now select only the correct CAID (0D95) in the list on the WEB UI.

Then I get this:

dvbcam: dvbca0-0/0x7fcdc528e300: match CAID 0D95 PID 0 (0000)
dvbcam: dvbca0-0/0x7fcdc528e300: add CAID 0D95 to selection
ddci: CAM ci2 assigned to 0x7fcdc528e300

When I tune now to a channel on the same transponder and the limit is set to 1, TVH will not find a CAM.

Then TVH should execute the start function of all other registered CA clients. This is done in "caclient_start" (caclient.c):

  TAILQ_FOREACH(cac, &caclients, cac_link)
    if (cac->cac_enabled)
      cac->cac_start(cac, t);

To prove that, you can add a debug line to "cclient.c" (I think this is used for OsCAM) after this line (1055):

 "extern const idclass_t mpegts_service_class;" 

The debug line:

  tvhtrace(LS_DVBCAM, "Card Client");

Start TVH with this parameters or enable the tracing in the GUI.

 -l tvh.log --trace linuxdvb,ddci,dvbcam

In fact the code in "cc_service_start" should then select the SW CAM.
If you see the added debug line, you need to add more debug code to "cc_service_start" to find why your SW CAM is not selected.
If you don't see the debug line, then add debug lines to "caclient_start" and find why it does not execute the start functions of all registered CAM class types. In "caclient_create"(caclient.c) all the CAM class create functions are executed.
Sorry, but I can't do more for you then explaining you how you can debug that.

BR,
Jasmin

Hi!

I think I was wrong with assuming OsCAM is handled by the cclient :(
It is handled by capmt, so you need to add the debug printing to "capmt_service_start".

BR,
Jasmin

Hi!

I will submit a pull request when some people did test this.

My pull request has been accepted!
DD CI MCD support is now available on TVH master.

With that the second phase of the DD CI integration is finished.
When I have time I will start with MTD (https://tvheadend.org/issues/4750), the third step. Please note, this is not that simple and requires to touch other parts in TVH beside the DD CI code (e.g.: CA-PMT generation). So this will require some design (eMails to Jaroslav) in advance. Don't expect this feature soon, as I will work at first on a CI related problem in the Kernel (EN 50221 protocol driver).

BR,
Jasmin

Maybe stupid question bit, is it can descramble services on different tuners/transponders on same TAB

can descramble services on different tuners/transponders on same TAB

No, because a tuner on the same TAB is also another tuner and therefore another mux/input for TVH.

Hi,

thanks for this cool piece of work! I am using an up-to-date Arch Linux machine with Tvheadend 4.3-1133~ge339005ab (just build today). I have a couple issues and I'd like to get your advice on them:

1. The descrambled stream apparently contains video only:
- Regardless of which stream profile I choose, VLC only reports (and plays) a singe stream (video).
- If I use Tvheadend to record the stream, VLC does the same thing with the recorded file. Also, TSDoctor (the software I use to cut recordings) reports that the scream starts scrambled. It offers to cut away these scrambled bits, ending up with only a video stream (and, curiously, a Teletext stream -- although I am not sure I'd trust this info).
- The Tvheadend log doesn't provide any clues, except maybe for the message "Invalid start code" (followed by some number, e.g. d8:95:b9) right when it starts the stream.

2. EMMs are apparently not sent (or written?) to the card. (Using the same CAM/CI combination in an Octopus Net box worked perfectly, so I don't think it's the hardware's fault.)

Does anyone have an idea what I could do about these issues?

1. The descrambled stream apparently contains video only:

I have no clue why this happens. The dvbcam code gets the PIDs to subscribe from the PAT/PMT. I never observed such a behaviour during my tests.
When you save record the resulting stream with

   wget -O a.ts "http://admin:admin@vdr-jasmin:9981/stream/channelname/ORF1 HD?profile=pass" 

  admin:admin -> username:password
  vdr-jasmin  -> IP of your TVH box
  ORF1 HD     -> service name

Then you can use DVBinspector (https://sourceforge.net/projects/dvbinspector/files) to analyse the a.ts file.
In should contain the PAT, PMT and all the A/V streams. Maybe you can find by analysing PAT/PMT what is wrong.

Also, TSDoctor (the software I use to cut recordings) reports that the scream starts scrambled.

This is normal because the CAM needs some time before it can decode. But is does decode, so all the required ECMs are sent to the CAM.

- The Tvheadend log doesn't provide any clues, except maybe for the message "Invalid start code"

I don't know what this means ... .

2. EMMs are apparently not sent (or written?) to the card.

There is code to subscribe the EMM PIDs. I can re-test if this is really working. Maybe there is a problem with the CAT decoder.
You could activate tracing for dvbcam (see above in this thread for more info). You should then see lines:

 "add EMM PID ??? (???) for CAID ???" 

Does anyone have an idea what I could do about these issues?

I have no idea, but we need to debug this with your help.
And you can contact me per eMail also.

BR,
Jasmin

Finally I had some time for some debugging...

After upgrading from jessie to stretch, I had some issues with the build of the openssl components...
After "fixing" it (dependency is libssl1.0-dev, not longer libssl-dev), I added some debug lines.

When switching to an oscam channel or an alphacrypt light channel, "caclient_start" and "capmt_service_start" are executed... at this level, there seems to be no difference...
Any idea what makes sense to check next?

When switching to an oscam channel or an alphacrypt light channel, "caclient_start" and "capmt_service_start" are executed...

Which is clear (I wrote this already in my previous post https://tvheadend.org/boards/13/topics/29639?r=31478#message-31478):
Then TVH should execute the start function of all other registered CA clients. This is done in "caclient_start" (caclient.c)

Any idea what makes sense to check next?

You need to add debug prints to dvbcam_service_start and capmt_service_start and find out which of the CA clients is used and why dvbcam_service_start wins. In Theory it should return without selecting the CAM for the new service, when there is no free slot available (limit set to 1).

BR,
Jasmin

Hello, I am not a DVB expert but I have been using my digitaldevices setup on windows for years and finally it seems a linux solutution is on the horizon!

Right now I am running the HTS Tvheadend 4.3-1500~g7185713f4~bionic version and I can finally get my CI to decode my channels, jay!! Only issue is that I have on CI CAM and that is shared on 4 tuners. On Windows I can share this CI and it is bought especially to have the ability to do 8 decodes in paralell if needed.

Is there any way I can enable to share this CAM for all my tuners? I am running on Mint 19 currently.

Thanks!

Got this email from Digital Devices:

The only what you can do is to make a redirect from one tuner to one CI, but you have no MTD and can only decrypt channels from one transponder.

Here you can find instruction how you can make a redirect:

https://github.com/DigitalDevices/dddvb/blob/master/docs/redirect

MTD is a hack in the Windows driver and only available in Windows, under Linux the TV software must support it.

A TV Software which should support this is VDR.

No input on this?

Attached a picture of my CA settings. When I hover over the "CAM can decode multiple channels" I see the text, enable MCD and MTD for this CAM so it seems the functionality is enabled but not working correctly.

Here is some data from my logs:

Nov  1 09:33:34 mint tvheadend[10691]: subscription: 0028: service instance is bad, reason: No descrambler
Nov  1 09:33:35 mint tvheadend[10691]: mpegts: 298MHz in DVB-C Network - tuning on ST STV0367 DDB DVB-C/T #3 : DVB-C #0
Nov  1 09:33:35 mint tvheadend[10691]: subscription: 0036: "epggrab" subscribing to mux "298MHz", weight: 4, adapter: "ST STV0367 DDB DVB-C/T #3 : DVB-C #0", network: "DVB-C Network", service: "Raw PID Subscription" 
Nov  1 09:33:35 mint tvheadend[10691]: mpegts: mux 354MHz in DVB-C Network old params DVB-C freq 354000000 sym 6952000 mod QAM/256 fec NONE ds 0 plp -1 (00020000)
Nov  1 09:33:35 mint tvheadend[10691]: mpegts: mux 354MHz in DVB-C Network new params DVB-C freq 354000000 sym 6952000 mod QAM/256 fec 3/5 ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 362MHz in DVB-C Network old params DVB-C freq 362000000 sym 6952000 mod QAM/256 fec NONE ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 362MHz in DVB-C Network new params DVB-C freq 362000000 sym 6952000 mod QAM/256 fec 3/5 ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 370MHz in DVB-C Network old params DVB-C freq 370000000 sym 6952000 mod QAM/256 fec NONE ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 370MHz in DVB-C Network new params DVB-C freq 370000000 sym 6952000 mod QAM/256 fec 3/5 ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 378MHz in DVB-C Network old params DVB-C freq 378000000 sym 6952000 mod QAM/256 fec NONE ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 378MHz in DVB-C Network new params DVB-C freq 378000000 sym 6952000 mod QAM/256 fec 3/5 ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 386MHz in DVB-C Network old params DVB-C freq 386000000 sym 6952000 mod QAM/256 fec NONE ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 386MHz in DVB-C Network new params DVB-C freq 386000000 sym 6952000 mod QAM/256 fec 3/5 ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 402MHz in DVB-C Network old params DVB-C freq 402000000 sym 6952000 mod QAM/256 fec NONE ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 402MHz in DVB-C Network new params DVB-C freq 402000000 sym 6952000 mod QAM/256 fec 3/5 ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 410MHz in DVB-C Network old params DVB-C freq 410000000 sym 6952000 mod QAM/256 fec NONE ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 410MHz in DVB-C Network new params DVB-C freq 410000000 sym 6952000 mod QAM/256 fec 3/5 ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 418MHz in DVB-C Network old params DVB-C freq 418000000 sym 6952000 mod QAM/256 fec NONE ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 418MHz in DVB-C Network new params DVB-C freq 418000000 sym 6952000 mod QAM/256 fec 3/5 ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 426MHz in DVB-C Network old params DVB-C freq 426000000 sym 6952000 mod QAM/256 fec NONE ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 426MHz in DVB-C Network new params DVB-C freq 426000000 sym 6952000 mod QAM/256 fec 3/5 ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 474MHz in DVB-C Network old params DVB-C freq 474000000 sym 6952000 mod QAM/256 fec NONE ds 0 plp -1 (00020000)
Nov  1 09:33:36 mint tvheadend[10691]: mpegts: mux 474MHz in DVB-C Network new params DVB-C freq 474000000 sym 6952000 mod QAM/256 fec 3/5 ds 0 plp -1 (00020000)
Nov  1 09:33:37 mint tvheadend[10691]: subscription: 0028: No input source available for subscription "10.0.0.114 [ tv | Kodi Media Center ]" to channel "TV Norge HD" 

These logs are captured when one channels live and working on one client and I try to play another channel on another client (both KODI). I have only two DVB-C cards running, and I have enabled them one at a time to check that they work. Is there any more tricks I should do?

This is my dmesg:

[ 6731.246159] ddbridge 0000:02:00.0: DVB: adapter 3 frontend 0 frequency 4294967274 out of range (48000000..864000000)
[ 6731.246501] ddbridge 0000:02:00.0: DVB: adapter 2 frontend 0 frequency 4294967274 out of range (48000000..864000000)
[ 6731.246787] ddbridge 0000:02:00.0: DVB: adapter 1 frontend 0 frequency 4294967276 out of range (48000000..864000000)
[ 6731.247110] ddbridge 0000:02:00.0: DVB: adapter 0 frontend 0 frequency 4294967285 out of range (48000000..864000000)
[ 6732.091670] dvb_ca_en50221: dvb_ca adapter 4: DVB CAM detected and initialised successfully
[ 7901.424178] perf: interrupt took too long (2540 > 2500), lowering kernel.perf_event_max_sample_rate to 78500
[ 8047.807309] dvb_ca_en50221: dvb_ca adapter 4: DVB CAM detected and initialised successfully
[ 8059.315281] ddbridge 0000:02:00.0: DVB: adapter 3 frontend 0 frequency 4294967279 out of range (48000000..864000000)
[ 8059.316445] ddbridge 0000:02:00.0: DVB: adapter 2 frontend 0 frequency 4294967281 out of range (48000000..864000000)
[ 8059.317556] ddbridge 0000:02:00.0: DVB: adapter 1 frontend 0 frequency 4294967276 out of range (48000000..864000000)
[ 8059.318820] ddbridge 0000:02:00.0: DVB: adapter 0 frontend 0 frequency 4294967286 out of range (48000000..864000000)
[ 8060.159265] dvb_ca_en50221: dvb_ca adapter 4: DVB CAM detected and initialised successfully
[ 8829.345902] dvb_ca_en50221: dvb_ca adapter 4: DVB CAM detected and initialised successfully
[ 8839.094109] ddbridge 0000:02:00.0: DVB: adapter 3 frontend 0 frequency 4294967285 out of range (48000000..864000000)
[ 8839.094686] ddbridge 0000:02:00.0: DVB: adapter 2 frontend 0 frequency 4294967285 out of range (48000000..864000000)
[ 8839.096071] ddbridge 0000:02:00.0: DVB: adapter 1 frontend 0 frequency 4294967276 out of range (48000000..864000000)
[ 8839.096583] ddbridge 0000:02:00.0: DVB: adapter 0 frontend 0 frequency 4294967281 out of range (48000000..864000000)
[ 8839.938050] dvb_ca_en50221: dvb_ca adapter 4: DVB CAM detected and initialised successfully

1. Sorry one image is wrong, but I dont know how to delete it.

Hello Stian!

Is there any way I can enable to share this CAM for all my tuners? I am running on Mint 19 currently.

No, this is currently not implemented!
I have too much other work and currently out of DVB development.
There is currently only one Linux tool which supports MTD namely VDR.
So DD is right.

I see the text, enable MCD and MTD for this CAM so it seems the functionality is enabled but not working correctly.

When I added this text I was commenting on the "multi" flag, which is used to differentiate between CAMs which can decode only one single channel or the other CAMs which can decode several channels. So this text is correct in my opinion, even MTD is currently not implemented, but planned.

And to answer your next question now:
I will not implement MTD in a recent time frame. MTD requires to rewrite all the PIDs within the different streams sent towards the CAM and rewrite them back to the original PID once they are read out again. This is not that complicated, but it requires also to rewrite control packets (CAT and other) which means to completely rewrite them. I forgot too much since I implemented MTD concerning all of this and as mentioned above, I have currently no time to work on this. I am even no TVH but VDR user, so my motivation to look into this is currently not quite high.
Moreover, there is still a problem in the Kernel with the CI state machine, which prevents old CAMs to work properly. And as a Kernel developer, I am more focused on that. This problem effects all CI interfaces and not only DD CI's. So it has definitely a higher priority.

BR,
Jasmin

Hello Jasmin, thank you so much for this response, even if I hoped for something else. At least I can cease my efforts getting TVH to descramble multiple channels. I really like the GUI and userfriendlyness of TVH compared to VDR so that is a pity.

So then I just have to find some way to make VDR work. If anyone knows of a forum or similar do discuss these things for VDR I would be happy for a pointer. VDR is narly to set up and very hard to understand. Documentation is also very limited ... I got it to work, scan channels and decode with the ddci2 plugin but still I am stuck at one stream decode on VDR (version 2.4.0 and ddci2 1.0.5). The thing is that I do not know if I have set it up for MTD, does my channels.conf get used by all devices? Are they enabled, linked etc, etc ... VDR is not that easy

But a topic for another day! Thanks for you lengthy response and hope you will find the energy to complete this at one time. At least count me in as a testuser! And thanks for the kernel work, love linux!

Jasmin Jessich wrote:

And to answer your next question now: I will not implement MTD in a recent time frame.

Thanks for all the support so far and for your detailed explanation. It would be nice if you wouldn't forget us completely and could implement MTD one day in the future, even if it takes the next years.

Stian B. Barmen wrote:

So then I just have to find some way to make VDR work. If anyone knows of a forum or similar do discuss these things for VDR I would be happy for a pointer. VDR is narly to set up and very hard to understand. Documentation is also very limited ... I got it to work, scan channels and decode with the ddci2 plugin but still I am stuck at one stream decode on VDR (version 2.4.0 and ddci2 1.0.5). The thing is that I do not know if I have set it up for MTD, does my channels.conf get used by all devices? Are they enabled, linked etc, etc ... VDR is not that easy

Hi Stian,

there is a German language forum at www.vdr-portal.de. The users there are generally very friendly (I am one of them) and willing to answer questions in English.
To quickly answer your question: yes, your channels.conf will be used by all devices. What you are probably missing for MTD with the ddci2-plugin is a vdr version > 2.3.8. If that is installed alongside the ddci2-plugin, MTD should work without any further configuration.
Please venture over to the vdr-portal for any other questions, as I don't want to fill the TVHeadend-Forum with off-topic vdr-posts.

BTW: I am also very grateful for Jasmin's work on TVH (and of course VDR) and hope that she (or somebody else) will find the time to implement MTD for TVH. Unfortunately this is far beyond my abilities.

Am I wrong to bump this? I would love this functionality in TVH so I could migrate from VDR. Is there anyone contemplating adding this support for MCD (Multi Channel Decryption)?

Sorry, but I am still too busy for this.
In fact I even have no time to fix an open issue with the CAM state machine in the Kernel.

MTD is the most complicated task, because you need to re-map the PIDs and in the meantime I lost most of my knowledge of the internals of TVH anyway.
In my opinion any good C/C++ programmer can analyse how it is done in VDR, define a concept and implement it in TVH. The implementation in TVH might be a bit more complex as in VDR, because of the way TVH does dispatch the stream to clients and where in the chain the CAM decoder is located. This will give problems in the PID re-mapping. But a good programmer will understand this and can implement it accordingly.

BR,
Jasmin

Jasmin Jessich why not make library with all apps can communicate with API no mater TVH VDR and etc.
This will reverse who will have implementation problems /in this case not you/

why not make library with all apps can communicate with API no mater TVH VDR and etc.

I thought already to do that, but TVH and VDR are so different that this was not possible.
They even use a different programming language. Beside that, the structure of VDR and TVH is also very different.
So this is not possible.

BR,
Jasmin

External library not internal something as softcam's aka "Jasmin_HW_Cam" ;)
It can work as Stream Relay or tsdecrypt for TS PS or ES streams.

+------------+      +----------------+  +---------+    +-----------+    +--------------+
|  DVB INPIT +----> | DVB APP        |  | TS      +--->+  FRONTEND |    | CLIENT       |
|            |      |                +->+ prcesor |    |           +--> |              |
+------------+      +----------------+  +-^----+--+    +-----------+    +--------------+
                                          |    |
                                      +---+----v---+
                                      |  CAM MCD   |
                                      |            |
                                      +-----+--+---+
                                            |  ^
                                            v  |
                                      +-----+--+---+
                                      |  CI MODULE |
                                      |            |
                                      +------------+

Hello,
so no news for MTD (Multi Tuner Decoding) on Digital Devices CI?
Any developer that could make this happen?
Even if we support him/her directly via kickstarter or some similar way?