Normal
I think that I have lost track of what is being proposed here. It seems to me that this thread is confusing two different capabilities:Retain strongestDuring "scan for channels", when a duplicate MUX is encountered (can occur when the user is midway between two different transmitters), "TV Server" should retain the stronger of the two MUXes, and discard the weaker.For this capability, there is no need for a signal-level threshhold. During scanning, TV Server remembers the signal level of each MUX. When the next MUX is found, TV Server compares the various ids with the previous MUXes that it found during the scan, to determine if the new MUX duplicates a previous MUX. If it does, TV Server retains the stronger of the two, and discards the weaker. Some understanding of how TV Server stores information during the scan is required so that the information for the weaker MUX can be discarded.This capability needs to be selectable by the user prior to scanning (i.e. a new setting on the "Scan for Channels" panel in TV Server).Omit weak MUXesPrior to the scan, the user specifies a signal-level threshhold that TV Server uses to accept or reject MUXes during the scan. MUXes which are weaker than this threshhold are ignored. MUXes which equal or exceed this threshhold are retained. Note that this does not discard duplicate MUXes (retention of duplicate MUXes may be the user's desired outcome, due to different local content on the two transmitters).It is important that this threshhold be user specifiable, as what one user considers to be a "weak" signal, another user may consider to be a "normal" signal. Example: there are nine MUXes that serve my location in the UK; all MUXes are broadcast from the same transmitter:(1) Three MUXes are broadcast with a power of 200 kW.(2) Three MUXes are broadcast with a power of 50 kW.(3) Three MUXes are broadcast with a power of circa 20 kW.So there are very-significant differences between the signal levels that I receive. If I had a roof aerial, I would want to use a low value for the signal-level threshhold, as I would be able to receive all nine MUXes. But with the loft aerial that I actually use, I would use a higher value for the signal-level threshhold, as the three low-power MUXes can be received, but not at acceptable quality for viewing (frequent pixelation of the picture).The user should be able to specify the signal-level threshhold on the TV Server "Scan for Channels" panel. The value should be in the range 0 to 100, with the default being 0. The value 0 is the value that gives identical behaviour to previous releases of MP.ConclusionsBoth of the capabilities described above are useful, but they are independent of each other. Either or both could be implemented, and would (I think) improve the product. But as far as I can see, the current change does neither, and so (reluctantly) I must vote against it being included in the next release of MP.I may have misunderstood what the new code does; if so, apologies. And of course it is possible for the new code to be reworked to provide either or both of the capabilities described above, at which point inclusion in MP should be reconsidered.-- from CyberSimian in the UK
I think that I have lost track of what is being proposed here. It seems to me that this thread is confusing two different capabilities:
Retain strongest
During "scan for channels", when a duplicate MUX is encountered (can occur when the user is midway between two different transmitters), "TV Server" should retain the stronger of the two MUXes, and discard the weaker.
For this capability, there is no need for a signal-level threshhold. During scanning, TV Server remembers the signal level of each MUX. When the next MUX is found, TV Server compares the various ids with the previous MUXes that it found during the scan, to determine if the new MUX duplicates a previous MUX. If it does, TV Server retains the stronger of the two, and discards the weaker. Some understanding of how TV Server stores information during the scan is required so that the information for the weaker MUX can be discarded.
This capability needs to be selectable by the user prior to scanning (i.e. a new setting on the "Scan for Channels" panel in TV Server).
Omit weak MUXes
Prior to the scan, the user specifies a signal-level threshhold that TV Server uses to accept or reject MUXes during the scan. MUXes which are weaker than this threshhold are ignored. MUXes which equal or exceed this threshhold are retained. Note that this does not discard duplicate MUXes (retention of duplicate MUXes may be the user's desired outcome, due to different local content on the two transmitters).
It is important that this threshhold be user specifiable, as what one user considers to be a "weak" signal, another user may consider to be a "normal" signal. Example: there are nine MUXes that serve my location in the UK; all MUXes are broadcast from the same transmitter:
(1) Three MUXes are broadcast with a power of 200 kW.
(2) Three MUXes are broadcast with a power of 50 kW.
(3) Three MUXes are broadcast with a power of circa 20 kW.
So there are very-significant differences between the signal levels that I receive. If I had a roof aerial, I would want to use a low value for the signal-level threshhold, as I would be able to receive all nine MUXes. But with the loft aerial that I actually use, I would use a higher value for the signal-level threshhold, as the three low-power MUXes can be received, but not at acceptable quality for viewing (frequent pixelation of the picture).
The user should be able to specify the signal-level threshhold on the TV Server "Scan for Channels" panel. The value should be in the range 0 to 100, with the default being 0. The value 0 is the value that gives identical behaviour to previous releases of MP.
Conclusions
Both of the capabilities described above are useful, but they are independent of each other. Either or both could be implemented, and would (I think) improve the product. But as far as I can see, the current change does neither, and so (reluctantly) I must vote against it being included in the next release of MP.
I may have misunderstood what the new code does; if so, apologies. And of course it is possible for the new code to be reworked to provide either or both of the capabilities described above, at which point inclusion in MP should be reconsidered.
-- from CyberSimian in the UK