Improve OTA mux scheduling when dealing with subscription failures

[smithereens]

Associate a retry count with each OTA mux subscription failure and abort after 3 delayed attempts.
In this context, failure includes repeated tuning errors, but excludes lack of adapter availability.

[Flole998]

I left some comments, those should be adressed before merging. Also please squash your commits together.

[perexg]

The three requests to subscribe a mux seems like a bad idea. The retry may be configurable, because there may be a good reason why the mux is not available. But I guess that the real problem is somewhere else (tuner / input problem?). If you have a complex setup, it's better to jump to an another mux and move the bad one to the end of queue.

The sec2mono() fix looks appropriate.

[smithereens]

there are 2 intended fixes in this pull request, the first one is about the swap of mono2sec(60) for sec2mono(60) - I believe the original intention was to have EPG to check every minute for the active mux to be complete before scheduling a new one, the swap basically means this check is done every 60 clock ticks instead; keeping the CPU quite busy.
the second fix is related to my pull request in #1398 - if the active mux is unable to tune to a transponder it will try to do so indefinitely until a higher subscription aborts the EPG scan. This change should gives a fair chance for a tune request to succeed; otherwise the MUX scan is aborted and EPG scan will move to the next one.

[smithereens]

The three requests to subscribe a mux seems like a bad idea. The retry may be configurable, because there may be a good reason why the mux is not available. But I guess that the real problem is somewhere else (tuner / input problem?). If you have a complex setup, it's better to jump to an another mux and move the bad one to the end of queue.

The sec2mono() fix looks appropriate.

I agree that the 3 strikes rule is not ideal when dealing with this problem but it allows the EPG scan to complete eventually. Moving the 'bad' subscription to the tail of the list does not seem to be appropriate for the use case i documented in #1398, but i must confess i'm not very familiar with this code, so may be there's a better way to do it.

[smithereens]

The three requests to subscribe a mux seems like a bad idea. The retry may be configurable, because there may be a good reason why the mux is not available. But I guess that the real problem is somewhere else (tuner / input problem?). If you have a complex setup, it's better to jump to an another mux and move the bad one to the end of queue.
The sec2mono() fix looks appropriate.

I agree that the 3 strikes rule is not ideal when dealing with this problem but it allows the EPG scan to complete eventually. Moving the 'bad' subscription to the tail of the list does not seem to be appropriate for the use case i documented in #1398, but i must confess i'm not very familiar with this code, so may be there's a better way to do it.

I double checked the code again and i believe the original code was already pushing unusable muxes to the tail of the queue, but the bad ones will be never be removed, and checked over and over once all the good ones have all been processed. My change is just cutting this short.

[Flole998]

The three requests to subscribe a mux seems like a bad idea. The retry may be configurable, because there may be a good reason why the mux is not available. But I guess that the real problem is somewhere else (tuner / input problem?). If you have a complex setup, it's better to jump to an another mux and move the bad one to the end of queue.

Do I understand it correctly that you suggest making it configurable? Or do you think that this retry-logic is a bad idea in general?