View Full Version : [VU+ Duo2] Wrong frequency displayed for DVB-C channels
The latest 4.0 build 3 vix image shows wrong frequency for DVB-C channels. The real channel frequency is 219.5 MHz but vix rounds up and displays as 220 MHz, I noticed this issue on:
- second infobar
- service information
- bottom of channel list
abu baniaz
27-03-16, 19:48
How is someone going to confirm this? Can you provide details of these channels, provider details, lamedb file.
When was it last correct?
abu baniaz
27-03-16, 21:13
The values are rounded to nearest MHz. It does not make a difference whether you scan 219.5 MHz or 220 MHz.
The latest 4.0 build 3 vix image shows wrong frequency for DVB-C channels. The real channel frequency is 219.5 MHz but vix rounds up and displays as 220 MHz, I noticed this issue on:
- second infobar
- service information
- bottom of channel listThat value is rounded to the nearest integer. MHz is the smallest unit that can be entered in manual scan so why should we display a smaller unit than this?
Abu, on the last vix 3.2 build 037 the frequency was displayed without round up, that means that 219.5 MHz was displayed as 219. Since I remember vix image never displayed the correct frequency, maybe is because VU base image just support integer numbers for DVB-C frequencies. I have a list of other issues regarding DVB-C support, but lets take one at a time.
I attached my lamedb and a couple of photos as you requested.
Huevos, probably because you are displaying wrong information...
Abu, on the last vix 3.2 build 037 the frequency was displayed without round up, that means that 219.5 MHz was displayed as 219. Since I remember vix image never displayed the correct frequency, maybe is because VU base image just support integer numbers for DVB-C frequencies.What is the point displaying a smaller figure than can be entered via manual scan?
Are you saying that the VIX team decided to display wrong information to the end users, because of a stupid limitation introduced by VU on the manual service search?
Are you saying that the VIX team decided to display wrong information to the end usersIt is not "wrong", it is rounded to the nearest MHz. What is your need for a greater level of precision than the receiver can detect?
What are you talking about? What precision? The receiver works with the right precision in Hz, as you can check on lamedb.
What you mean is that the "smart" development team at VU made a huge mistake by allowing only integer MHz values for DVB-C channels, and because of that you and all other teams that depend on VU base image can't do much about it.
Don't waste your time convincing me that round up a frequency is a minor problem and the right thing to do. Focus your efforts asking VU to do a proper DVB-C support on their boxes.
What are you talking about? What precision? The receiver works with the right precision in Hz, as you can check on lamedb.
What you mean is that the "smart" development team at VU made a huge mistake by allowing only integer MHz values for DVB-C channels, and because of that you and all other teams that depend on VU base image can't do much about it.
Don't waste your time convincing me that round up a frequency is a minor problem and the right thing to do. Focus your efforts asking VU to do a proper DVB-C support on their boxes.
Perhaps you should post your "requirements" to VU+ , don,t blame the pig in the middle :) ... The blame lies with VU+ so get your pen out and do some thing positive:)
Rob van der Does
29-03-16, 06:51
Abu, on the last vix 3.2 build 037 the frequency was displayed without round up, that means that 219.5 MHz was displayed as 219.
So that's a round-off as well!
Anyway: for the info to be displayed you can choose between the data that's in the lamedb and the data that's provided by the tuner. Both can (and often are) different, because of the accuracy limitation of the tuners. The very same applies to satellite tuners.
PS: No need for such a tone. We do not 'invent' or make up anything in this area, but we are depending on the hardware.
Hi,
why do you need 0.xMHz? Each frequency has a bandwidth which is I think 8MHz and they use PLL to fix the signal.
ciao
What are you talking about? What precision? The receiver works with the right precision in Hz, as you can check on lamedb.Open "Manual Scan". The smallest frequency unit that can be entered is MHz. That is why this value is truncated to the nearest MHz in the skin and info screens.
Previously "219" was displayed. That is because Python in-built rounding is always towards negative infinity. Now "220" is displayed. This is because Abu asked for the value to be changed to reflect conventional rounding.
Values in lamedb, satellites.xml, etc. are false precision (https://en.wikipedia.org/wiki/False_precision), and far beyond what the hardware is capable of differentiating.
abu baniaz
29-03-16, 11:21
Putting aside the accuracy debate.
Is it not possible to enter a rational number when you know it. This is a programming limitation in the image.
EDIT: I had asked for rounding to be done to the nearest MHz. If we can adapt the code to display rational numbers, then that would be an improvement in my view.
Is it not possible to enter a rational number when you know it. This is a programming limitation in the image.I can't see the "rational" of this.
No, it is not a limitation of the software. The software is capable of doing maths to many decimal places. But to the hardware all those decimal places are meaningless. For example if I want to scan 10818V I can input 10822V in manual scan and it will find the transponder no problem. And in cases where the transponders are extremely close together the STB cannot decide which is on what frequency and tunes either on subsequent zaps.
abu baniaz
29-03-16, 12:26
the rationale is simple. I know the frequency to be scanned is 383.750. This is what the broadcaster uses. Surely I should be able to enter this value.
We are discussing what user can input and see.
I still don't get it. Why display a value that cannot be entered in manual scan?
abu baniaz
29-03-16, 21:26
That makes two things that have to be changed then.
Rob van der Does
30-03-16, 08:06
I still don't get it. Why display a value that cannot be entered in manual scan?
Or with different words: why enter a more-detailed number that won't be used by the tuner?
abu baniaz
30-03-16, 12:20
Can you expalin why there are .125, .375, .500 and .750 entries in the cables.xml file?
Can you expalin why there are .125, .375, .500 and .750 entries in the cables.xml file?No idea, I didn't create the file. Satellites.xml is rounded to the nearest MHz value.
That makes two things that have to be changed then.I've never seen an STB that takes frequency input in anything but MHz values. Why make a user enter 6 figures when only 3 are required?
Can you expalin why there are .125, .375, .500 and .750 entries in the cables.xml file?Now I'm even more confused :confused:
Cables.xml has stuff like this in it...
<transponder frequency="218750000" symbol_rate="6952000" fec_inner="3" modulation="5" inversion="1"/>
<transponder frequency="219000000" symbol_rate="6952000" fec_inner="3" modulation="5" inversion="1"/>
Two entries pointing at the same transponder.
abu baniaz
30-03-16, 18:27
There are at least three ways to look it. If answer is given in one view and it is intepreted in another view there will always be confusion.
Programming
Hardware issues
End user's interaction
Most software is written to fulfil user's requirements, so hopefully discussion can remain in that context.
Oh yes, step scan allows you to scan in less than 1 MHz intervals when it works.
Is there any reason to have multiple entries for the same transponder? IMO, that really is adding to confusion, and causing double scanning. That file is being edited by all different people so it is a mixture of styles. Some providers have been rounded to nearest MHz value, while others are using kHz. Where it is definitely wrong is where both styles have been used (causing multiple entries).
abu baniaz
30-03-16, 19:03
Nobody maintains that file. We are even missing the 6887 entries for the UK ( I'll ask PaphosAL to get generate a list for us). You do a wonderful job on the satellite section, however you do not use a cable tuner. The cable providers are all different. With all due respect, you are assuming that they have been rounded off.
When the exact values for the provider are known, then those should be used. Even ABM uses the rational numbers, not nearest integers.
For "blind scanning" then, yes no need for the exact figures as they will be picked up on the integer entry. We should even use automatic entries for the values that we can. That will make scanning easier
Abu, I contribute and maintain the NOS cable operator entry on cable.xml, I can confirm that the frequency on the file is in Hz.
With all due respect, you are assuming that they have been rounded off.Look at lines 6248 and 6249. Two entries pointing at the same transponder. There are others like this. Just means the receiver will double scan the same transponder. Bandwidth is 8MHz in this part of the band so it is impossible they are different transponders.
Getting an accurate list would be a good start.
Yes, ABM does write sub-MHz values to lamedb, because that is what is carried in the SI tables.
Abu, I contribute and maintain the NOS cable operator entry on cable.xml, I can confirm that the frequency on the file is in Hz.Yes, they are in hertz, but, what is being discussed here is false precision (https://en.wikipedia.org/wiki/False_precision).
the number of significant figures used in the presentation of data should be limited to what is warranted by the precision of those data. For example, if an instrument can be read to tenths of a unit of measurement, results of calculations using data obtained from that instrument can only be confidently stated to the tenths place, regardless of what the raw calculation returns or whether other data used in the calculation are more accurate. Even outside these disciplines, there is a tendency to assume that all the non-zero digits of a number are meaningful; thus, providing excessive figures may lead the viewer to expect better precision than actually exists.
Rob van der Does
30-03-16, 19:46
How could frequency in Hz be of any interest when the bandwidth is 8MHz?
abu baniaz
30-03-16, 19:52
It is no point discussing this further until the end goal is defined. When one person talks about A and another person talks about B, there will always be confusion. No progress will be made.
How could frequency in Hz be of any interest when the bandwidth is 8MHz?When we did the Blindscan plugin one of the biggest improvements was removing those long numbers that no one understood.
Rob van der Does
31-03-16, 03:14
Exactly .
abu baniaz
31-03-16, 06:17
Exactly .
It is not permissible to be exact. We must round to nearest integer.
abu baniaz
31-03-16, 07:23
An article on nearest integer. explains why rounding upwards is done and not down.
https://en.wikipedia.org/wiki/Nearest_integer_function
Rob van der Does
31-03-16, 08:17
The article shows that rounding-off is being done, not specific rounding-up or rounding-down. Also see
https://en.wikipedia.org/wiki/Rounding
So 1.49 is rounded-off as 1, and 1.50 is rounded off as 2 (i.o.w. the normal mathematical rounding-off).
Since this long discussion is inconclusive, may I suggest to follow other images approach to truncate the frequency to MHz.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.