Tvheadend

--trace descrambler,capmt,cwc - https://tvheadend.org/projects/tvheadend/wiki/Traces

$ ./build.linux/tvheadend --subsystems | grep descrambler
  descrambler     Descrambler
  descrambler-emm Descrambler EMM

Your key source is not reliable, here is the change for both keys (which is basically invalid - only one key /odd,even/ should change after 15 seconds in your case):

2017-11-26 19:04:24.152 [  DEBUG]:capmt: localuser: CA_SET_DESCR adapter 0 par 0 idx 0 cf79024a59279e1e
2017-11-26 19:04:24.153 [  DEBUG]:capmt: localuser: CA_SET_DESCR adapter 0 par 1 idx 0 dd0afde4ca9673d3

The 'Invalid start code' checks were added to 4.2, the previous version just ignored them.

Jaroslav Kysela wrote:

Your key source is not reliable, here is the change for both keys (which is basically invalid - only one key /odd,even/ should change after 15 seconds in your case):

[...]

The 'Invalid start code' checks were added to 4.2, the previous version just ignored them.

So, when both keys (even/odd) change at the system time, video freezes until the key for the next time interval is received, in the same way that if I didn't receive the key on time, isn't?. In previous tvheadend, what was done? Discard the key (odd/event) that shouldn't change in that time interval?

Launching 'tvheadend --subsystems ...' generates the same output appearing in your post, although that I can't trace descrambler subsystem :?¿?

When you says the key source is not reliable, is there any way to know/trace if the root cause is the key provider or Oscam dvbapi implementation itself?. I tested with Oscam latest version (net protocol), and a very old one r9XXX (tcp protocol) with the same outcome.

r 2 wrote:

Jaroslav Kysela wrote:

Your key source is not reliable, here is the change for both keys (which is basically invalid - only one key /odd,even/ should change after 15 seconds in your case):

[...]

The 'Invalid start code' checks were added to 4.2, the previous version just ignored them.

So, when both keys (even/odd) change at the system time, video freezes until the key for the next time interval is received, in the same way that if I didn't receive the key on time, isn't?. In previous tvheadend, what was done? Discard the key (odd/event) that shouldn't change in that time interval?

No, appearently tvh is using the received wrong key, so the stream is not descrambled properly. I doubt that the old version of tvh works, too (if you see those double-key-updates).

Launching 'tvheadend --subsystems ...' generates the same output appearing in your post, although that I can't trace descrambler subsystem :?¿?

I've never seen this issue before. It means that something is wrong. but it's rpi so the debugging possibilities are limited.

When you says the key source is not reliable, is there any way to know/trace if the root cause is the key provider or Oscam dvbapi implementation itself?. I tested with Oscam latest version (net protocol), and a very old one r9XXX (tcp protocol) with the same outcome.

You probably receive wrong keys from your parent server.

You may give a test with cwc (newcamd), but you'll probably hit the same issue.

Jaroslav Kysela wrote:

r 2 wrote:

Jaroslav Kysela wrote:

Your key source is not reliable, here is the change for both keys (which is basically invalid - only one key /odd,even/ should change after 15 seconds in your case):

[...]

The 'Invalid start code' checks were added to 4.2, the previous version just ignored them.

So, when both keys (even/odd) change at the system time, video freezes until the key for the next time interval is received, in the same way that if I didn't receive the key on time, isn't?. In previous tvheadend, what was done? Discard the key (odd/event) that shouldn't change in that time interval?

No, appearently tvh is using the received wrong key, so the stream is not descrambled properly. I doubt that the old version of tvh works, too (if you see those double-key-updates).

Launching 'tvheadend --subsystems ...' generates the same output appearing in your post, although that I can't trace descrambler subsystem :?¿?

I've never seen this issue before. It means that something is wrong. but it's rpi so the debugging possibilities are limited.

When you says the key source is not reliable, is there any way to know/trace if the root cause is the key provider or Oscam dvbapi implementation itself?. I tested with Oscam latest version (net protocol), and a very old one r9XXX (tcp protocol) with the same outcome.

You probably receive wrong keys from your parent server.

You may give a test with cwc (newcamd), but you'll probably hit the same issue.

Thank you very much for your feedback, so if I understand it correctly, this isn't a bug really and could be closed.

One last question, would it be possible for Tvh to detect such situations, like changing even/odd keys at the same time, where it's not being able no decrypt the stream and use other key provided from a second CA?.
I have setup two of these bad key providers in two different Oscam instances and setup two different CAs in Tvh pointing to the previous ones?. I see Tvh is requesting to both oscam servers the same keys at the same time, but it's seems that it's only using the key it received first to decrypt the stream. It would be great than in case Tvh isn't able to do it, like when reporting "The Invalid Start Code XX:XX:XX", to try to decrypt it with one of the others keys received from other active CAs registered in Tvh.
I tried to dig if it would be possible to implement the same from Oscam side, but it seems currently Oscam is not smart enough to detect this invalid keys.

TVH does not know if key is valid or invalid. It just use the provided key. The 'Invalid Start Code' is just a consequence when tvh tries to parse the broken data stream. If you have more key sources, you may configure oscam to 'verify' key http://www.streamboard.tv/wiki/OSCam/en/Config/oscam.conf#double_check . But it's expensive, indeed.

Thanks for the trick, I'm giving it a try. The issue that I see is that most of the times these providers give you with something like 3 to 6 simultaneous lines to compensate its bad service quality so it would by funny that at the end the one cccam server would be double checking the key given by the same provider but different cccam line. Trying to play at the moment with server weights in oscam load balancer to check if i'm able to avoid this.