Send all ECMs optionally

[lars18th]

By default when a key is invalid the same ECM is not resended to the server. This default behaviour has sense when the server has returned an invalid key for the ECM. However, with some busy cards resending the same ECM to the server will obtain a valid key. A new option is added to handle this specific case.

This new optionally parameter enables the passthrough of all received ECMs for a running service. By default only required ECM are passed to the DVBAPI server. This limits the bandwith and it's the common behaviour. However, in some specific cases it's preferable that the DVBAPI handles all ECMs. This option enables this. But take note that this could overload your server. Use with caution and only if it's necessary.

[lars18th]

This new option has sense with DVBAPI servers that can handle repeated ECMs. In my case is fully working. However, by default is disabled to not generate side effects.

[lars18th]

Hi @catalinii ,

To understand this PR:

• Current behaviour: When the DVBAPI returns a timeout/invalid/incorrect key for one ECM and the decoding fails, then minisatip doesn't try any other ECM for the same parity using the same CAID. Therefore it's necessary to wait for the next parity ECMs to ask for a new key.
• New behaviour (enabled with the parameter and disabled by default): When the DVBAPI returns a timeout/invalid/incorrect key for one ECM and the decoding fails, then minisatip pass to the DVBAPI server all received ECMs for the current parity (after 1 second of margin). Therefore when the decoding fails the same ECM or any other for the same parity will be sended. In this second try perhaps you'll receive a valid key. This is true if the server has a busy card (for example, if you want to decode more than one channel). However, it's necessary that you configure the DVBAPI correctly to return a timeout in a short time and clear the cache of failed ECMs.

[catalinii]

@lars18th if you check line 642 in dvbapi.c is supposed to re-send the ecm of the valid CW does not exist?

Any idea why that fails for you?

[lars18th]

Hi @catalinii ,

@lars18th if you check line 642 in dvbapi.c is supposed to re-send the ecm of the valid CW does not exist?

Any idea why that fails for you?

I've refactored the PR. The obscure cause of this option is because when you can receive different ECMs for the same key period (that's not identical ECMs for the same CAID). So, I've rewrited it with a simple implementation. Now it will be possible to passthrough all received ECMs to the DVBAPI server. Then it will be the responsability of your DVBAPI server to handle them.

Please, check it.

[lars18th]

Hi,

Perhaps you think this change doesn't provides any new functionality. However, it does no harm to anyone. But it opens the option to delegate the ECM control to your DVBAPI server. Therefore it's useful for investigation. So I don't see any reason to not approve it.

Please, review it.

[catalinii]

Basically you are saying that it is possible to get 2 different ECMs with the same parity before a CW parity change?

If that is the case why not do a CRC of the send ECMs and re-send new ones?

[lars18th]

Hi @catalinii ,

Basically you are saying that it is possible to get 2 different ECMs with the same parity before a CW parity change?

Yes. And not only two, but more than two. Anyway, please think that this option only disables the control done by minisatip over sended ECMs to the DVBAPI. If the DVBAPI server can handle this, then it will take the responsability of processing all ECMs. I repeat: this doesn't harm to any user (default off). So it's safe to incorporate it. And it opens the option to delegate this ECM control to another piece of code. Why not add it then?

[lars18th]

Hi @catalinii ,

If that is the case why not do a CRC of the send ECMs and re-send new ones?

This patch is not to improve minisatip internally or implementing support for new CAMS. It's only to delegate the control of the ECM management to the DVBAPI server. Nothing more. However, it's very useful, so please accept to merge it.

[catalinii]

I understand what you mean, but I am trying to identify if this could be a problem for any other user. If yes a CRC / SHA could be a way to do this automatically

[lars18th]

Hi @catalinii ,

I understand what you mean, but I am trying to identify if this could be a problem for any other user. If yes a CRC / SHA could be a way to do this automatically

Sorry for this question, but in which way could this generate a problem? First it's an user option off by default. Second I'm using it for a long time without troubles, so it's safe to use it. Therefore, if you want to improve it in the future, then you could do it. Remember: if the DVBAPI server can handle all ECMs then you don't need to worry about this function.

[catalinii]

I agree it does not generate a problem, but it is more about not resolving a problem twice. If any user can notice what you're experiencing then it is better to fix it now. Not fixing it now could lead to degraded user experience. As you experience the problem you can say if this can affect the users watching the same channels as you.

[lars18th]

Hi @catalinii ,

I'm not experimenting any problem. What I'm doing is not using minisatip to control (manage) the ECMs. I've delegated this to my DVBAPI server. Nothing more. I think in the future this will be necessary for some systems, and then the client will could work in managed mode (filtering ECMs) and not-managed (passing all). This patch provides this alternative mode.

[catalinii]

Thanks