-
-
Notifications
You must be signed in to change notification settings - Fork 912
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve OTA mux scheduling when dealing with subscription failures #1399
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left some comments, those should be adressed before merging. Also please squash your commits together.
bd3ff7e
to
545d1af
Compare
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. |
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. |
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. |
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.
892c862
to
03abe2d
Compare
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. |
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? |
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.