Tvheadend

I know, you won't like the answer, but: Forget it!

Some time ago I bought a an Alphacrypt Light Module, a programmer and a Digital Devices Octopus Twin CI v4, altogether cost around 250 € and I never managed to use it!
Then I bought an Easymouse2-Reader for just 20€, installed Oscam and everything works without problems ...
A hardware module seemed the more elegant solution to me and I feared the complexity of installing Oscam, but indeed it was quite easy.
Decyrpting HD+ channels like Sat.1 or RTL takes about 400 milliseconds.

The interesting question (from a programmers point of view) is: Why does it not work? What exactly is causing packets to get lost here. The idea is to forward the encrypted stream to the slot and then receive the unencrypted stream, right? So there are 2 places where things could go wrong: Sending to the module or receiving from the module. I would assume that the packet count might be a good hint here, at least is something is really missing.

Does it work with any other software? It might not be a tvheadend problem at all.

M. Bergmann wrote:

I know, you won't like the answer, but: Forget it!

I know: there is a solution.

Some time ago I bought a an Alphacrypt Light Module, a programmer and a Digital Devices Octopus Twin CI v4, altogether cost around 250 € and I never managed to use it!

I've tested the behaviour with an Octopus Net M4 with CI Slots: the non CI+ channels (Pro 7 HD / Sat 1 HD / K1 HD)
where working without problems ! I've seen for hours not a single CC error.

Digital devices uses a kernel 3.17 which is heavily patched on atmel and uses "there own" code. (It's
funny to look into the Octopus Code: you can look back in the DVB history.)

Problem: OctoNet is a SAT>IP box and within SAT>IP descrambling is client-ony. So you have to use a parameter for
the ci-slot within the the rtps request (x_ci=1). TVH as frontend does not work, because the special paramters are
not there: so frontend calls from TVH will fail, because the OctoBox needs the ci parameter.

But I have to have a single frontend to all clients. Yes - m3u channel list may work: brrrr.

Its really bad: the DD drivers work flawlessly for alle non-encrypted channels - but there is something rotten
for streams which are running thru the cam.

(I'll try the other solution.)

Flole Systems wrote:

The interesting question (from a programmers point of view) is: Why does it not work? What exactly is causing packets to get lost here. The idea is to forward the encrypted stream to the slot and then receive the unencrypted stream, right? So there are 2 places where things could go wrong: Sending to the module or receiving from the module. I would assume that the packet count might be a good hint here, at least is something is really missing.

Exactly this has been done with the test above: send the encrypted stream from one TVH instance (without CAM) to an
TVH instance where a CAM is available: Continuity counter error on the instance where decryption is done - no errors
while getting the stream from the reception card.

and suddently you are deep within PID handling and tsdemux.c ........

Does it work with any other software? It might not be a tvheadend problem at all.

Yes. Octonet works / dd-tv on windows works for all non CI+ channels.

[Exkurs]
Flo, melde dich bitte bei mir per Mail.
[/Exkurs]

It works with minisatip. You can just install minisatip and use it as a sat2ip tuner in tvheadend.
With a little research and the right certificates from enigma CI+ 1.3 also works with a recent minisatip

Hmmm. Wait...... clone, ddci=1, etc....

Wonderful : non encrypted channels can be called out-of-the-box.

While calling encrypted channels the log proves that something is happening.

I'll try it.

.... next day ......

OK: minisatip decrypts nearly out-of-the-box.

From an tvh frontend I scanned the spectrum with minisatip on another box. In contrary
to an thv-thv setup the tvh-msi setup works also without problems.

After the encrypted channels have been scanned I can call them directly from the tvh
frontend without using a crappy m3u solution.

There are only a couple of minor shortcomings:

- I have to use the first slot of the Digital Devices Duoflex CI.
Smells like the implementation is coded for the one-slot-CI.

- When selecting another crypt channel the first channal stops.
Hmm.

- It (currently) works only for non CI+ channels
Fine - that was my expectation for the out-of-box behaviour.

- There are no problems with PIN issues on msi.

- There are basicaly no ContinuityCounter Errors
After 5 hours of cont. streaming the decrypted stream I have only seen
a couple of errors: usually when the advertising block starts.

O.K.: That fully confirms a lot of my assumptions. Maybe I should write an HOWTO.

Thx.

for multi channel decoding you need a CI module that supports it. like Alphacrypt etc.
to get full CI working take a look at this thread, just look at how and where to put the certificates, support is already in minisatip: https://minisatip.org/forum/viewtopic.php?f=5&t=419

Tom W wrote:

O.K.: That fully confirms a lot of my assumptions. Maybe I should write an HOWTO.

Please do!

Addendum:

In the meanwhile I have disabled all descrambling activities within tvheadend and
switched to "the other solution".

No errors anymore. NO errors. More channels and: MTD.

Switching back to the "tvheadend ddci solution" every 10-15 seconds the cc errors are back.