DVB Tuner requires to improve when LOCK fails

[lars18th]

Hi @catalinii ,

With my Enigma2 STB running minisatip I see this problem: When some request doesn't arrives to LOCK the signal, the minisatip doesn't tries to recover for this. For example: if you request a transponder that implies a change in the diseqc and it fails to arrive to the correct LNB, then the tuner never receives the correct signal. In this case the DVB adapter handle never gets the LOCK. But the minisatip process continues with the session opened. My idea is to close the session if this fails, or retune the transponder. This will also applies if the LOCK is lost, to try to recover fro this case instead of continue streaming nothing.

You have any idea to improve this? Regards.

[lars18th]

Hi @catalinii ,

No ideas?

[catalinii]

Hey @lars18th,

so there are 2 issues here: 1) a client that does not have a LOCK on a particular TP because the signal is bad.

• for this one I am afraid we should not do much 2) minisatip potentially causes the tune to be incorrect.
• I think we should fix the cause. For example for slow JESS LNBs we did this: https://github.com/catalinii/minisatip/blob/master/src/dvb.c#L1857

[lars18th]

Hi @catalinii ,

Thank you for the response. To be more concise... the problem of a failing tuner (==no LOCK), and sssuming that the signal is good, could pass in two circunstances:

1. When the driver or the physical tuner has some trouble. Sometimes this pass with some low end hardware. In this case a reopening (close and open) of the frontend solves the problem. And in case of remote SAT>IP servers, the satipc can TEARDOWN the session and SETUP a new one. In both cases, the entire chain will be reset and the signal will normally be locked.
2. The other case is when the diseqc/jess fails in the operation to set the changes to provide the correct signal over the incomming wire. In this case, a resending of the commands will certainly solve the problem.

The idea is to provide a method to improve the robustness when minisatip detects that the signal is not locked. You think that you could improve this? Regards.

[catalinii]

I think we can try to improve it but basically deal with each source separately.

• source dvb: find 2-3 scenarios in which this happens and try to fix it
• source satip: find 2-3 scenarios in which this happens and try to fix it

[lars18th]

Hi @catalinii ,

Here two scenarios that I've discovered:

• Source dvb: With one E2 STB, connected to a wire with more than one SAT>IP servers connected to it (sharing the same LNBs) sometimes the DiseqC command is not processed. Then when configuring the tuner the signal never locks. I can test this using the "dvb-fe-tool". And in some edge cases the tuner will disappears from the minisatip. The solution is to restart the daemon (the minisatip process). One solution then could be: after some time (1 or 2 seconds, user defined) if the tuner doesn't lock, then resend the DiseqC commands. And after another timeout (5 seconds?), close and reopen the frontend.
• Source satip: With one low cost SAT>IP STB (closed sourced, not E2), if the tuner can't lock the signal, the streaming continues but no data is received. I'm not sure if the status RTCP indicates lock or not. But in any case, if the satipc module doesn't receive data, it has sense to send a TEARDOWN and reopen with a SETUP/PLAY after some time.

From my point of view, in general the timeout could be at adapter level: if the adapter can't receive anything until a short period, then the minisatip process (user selectable) could trigger a reopening. What you think?