search

oe-alliance / AutoBouquetsMaker

Automatically build and update bouquets from the DVB stream.
GNU General Public License v3.0
22 stars 59 forks source link

DVB-T Frequency Finder #100

Closed EMJB closed 5 years ago

EMJB commented 5 years ago

This currently uses signalQuality to compare signals to decide which is best. With the new API frontend.cpp derives this parameter from SignalQualityDB by applying an upper limit equal to the expected maximum SNR, and then rescaling to give a % figure. Hence if signalQuality provides a valid comparison between muxes, then signalQualitydB would also do so. However if (as is currently the case with the version used by OpenVix) the upper limit is too low or the scaling of SignalQualitydB is wrong, SignalQualitydB provides a valid comparison butSignalQuality does not.

I believe the logic for the earlier API in frontend.cpp is prone to similar errors, particularly where there is no logic specific to the tuner model in question - e.g. Si2169 reports a SignalQualitydB figure ten times too high and hence the signalQuality value is always 100%.

Thus changing the comparison to signalQualitydB would appear to have no disadvantages, and allow Frequency Finder to operate successfully with recent versions of Openvix and be less likely to be confused by shortcomings in frontend.cpp or tuner drivers if the user selects legacy stats or the new API is not supported.

EMJB

AbuBaniaz commented 5 years ago

Why are you reposting what you posted on the forum over several threads.

If you have a better way of doing this, provide the changes and they will be reviewed tested and adopted if deemed appropriate.