Bug #2913
Scanning incorrect frequencies
0%
Description
On backend 4.0.3 using Openelec 5.95.1 I have noticed two different issues using a DVB-S adapter.
The first is on network discovery, where frequencies are generated sometimes with added .25 or .50 on the end of the frequency making the multiplex off frequency. This reproduces as artefacts on screen.
The second is a mux scanning issue. Using Sky News on Astra 28 degrees as an example, it should appear FTA on 12207V. The frequency scanned shows services on transponder 11343V. I am using a standard universal LNB but cannot find any way to set a manual LO frequency to see if this will make a difference, however I should not need to do this.
Thanks
History
Updated by Jaroslav Kysela over 9 years ago
Frequencies are read from tables broadcasted in the MPEG-TS feeds. They contain also sub-MHz parts. Most software does not show this part. If you don't like it, just put the transpoder parameters manually.
The second question - I doubt that it's tvh fault. TVH trusts the driver that the given frequency is tuned and data are received from this frequency. The universal LNB settings is default:
.lnb_low = 9750000, .lnb_high = 10600000, .lnb_switch = 11700000,
Updated by Rob Rob over 9 years ago
Jaroslav Kysela wrote:
Frequencies are read from tables broadcasted in the MPEG-TS feeds. They contain also sub-MHz parts. Most software does not show this part. If you don't like it, just put the transpoder parameters manually.
The second question - I doubt that it's tvh fault. TVH trusts the driver that the given frequency is tuned and data are received from this frequency. The universal LNB settings is default:
[...]
I think the point to 1. is that they are actually incorrect.
In all situations on the Astra 28.5/28.2e satellites the .25/.50 addition to the frequency is always incorrect. This is a behaviour that a long time ago wasn't present in tvheadend.
It actually makes the difference between being able to tune a mux and not being able to, even on reasonable signal strength.
Updated by B C over 9 years ago
they are correct, take a look at kingofsat.net
further more a tuner is able to lock a 27mhz transponder even a few mhz from the center frequency away. all your devices (lnb, tuner) are for sure not exactly accurate and through the whole operating temperature float around a bit but that is only an issue on narrow scpc transmissions. the tuner is capable of adjusting the offset dynamically on a quit wide range on standard tv transponders.
Updated by Rob Rob over 9 years ago
B C wrote:
they are correct, take a look at kingofsat.net
further more a tuner is able to lock a 27mhz transponder even a few mhz from the center frequency away. all your devices (lnb, tuner) are for sure not exactly accurate and through the whole operating temperature float around a bit but that is only an issue on narrow scpc transmissions. the tuner is capable of adjusting the offset dynamically on a quit wide range on standard tv transponders.
They are incorrect, of course kingofsat/lyngsat has been checked, this is a bug report and not a discussion group.
Example...
CNC World on 11426.*00*
http://en.kingofsat.net/detail-cncworld.php
Eutelsat 28A 11426.*00*
tvheadend = 11426.*33*
Yes a tuner can 9/10 still pick that up, but we're dealing with 80+ muxes here in the UK on 28.5/28.2.
It's not random, good tuning is a balance, it's impossible to not have a few muxes that don't have optimal signal strength and when one of these is encountered that are using the incorrect frequency = artifacts.
I have a few muxes where just dropping the .xx changes the signal from a bad to a good one.
This is an issue, and not correct behaviour.
Updated by Jaroslav Kysela over 9 years ago
The frequency is read from the descriptor provided by broadcaster in the MPEG-TS DVB NIT service information table. The frequency part is decoded as:
frequency = (bcdtoint(ptr[0]) * 1000000 + bcdtoint(ptr[1]) * 10000 + bcdtoint(ptr[2]) * 100 + bcdtoint(ptr[3])) * 10;
Patch to print these frequencies to stdout:
diff --git a/src/input/mpegts/dvb_psi.c b/src/input/mpegts/dvb_psi.c index e189119..c42528d 100644 --- a/src/input/mpegts/dvb_psi.c +++ b/src/input/mpegts/dvb_psi.c @@ -196,6 +196,8 @@ dvb_desc_sat_del frequency = (bcdtoint(ptr[0]) * 1000000 + bcdtoint(ptr[1]) * 10000 + bcdtoint(ptr[2]) * 100 + bcdtoint(ptr[3])) * 10; + mpegts_mux_nice_name(mm, buf, sizeof(buf)); + printf("%s: freq: %d\n", buf, frequency); symrate = bcdtoint(ptr[7]) * 100000 + bcdtoint(ptr[8]) * 1000 + bcdtoint(ptr[9]) * 10 + (ptr[10] >> 4);
TVH just uses this frequency, because there's no reason to not trust the broadcasted information.
The other questions is if this information is correct, or if the hardware tuner has trouble with it. Most hardware tuners are not picky for the exact frequency and they scan all around frequencies (+-5Mhz or so) - they use PLL to lock, so the frequencies may slightly differ. I don't believe that anything +-2Mhz makes a difference - and if yes - probably the driver is broken.
Previous TVH versions didn't show the sub-MHz part, but it was there - you may check the mux config files.
Updated by Prof Yaffle over 9 years ago
I've been watching the thread on the Kodi forum... is there any way to maybe narrow down whether dropping the fractional frequencies does make a difference? Or perhaps whether it makes a difference to some particular drivers?
I'm well aware of the 'we shouldn't have workaround for buggy drivers/firmware/hardware' position, but the truth is that we do. If it can be proven that the <1kHz pieces do create a problem then we could maybe have a GUI option to ignore them. I don't know how hard that would be, and I know it's not the right thing to do, but reality is out there and people have to blame the software they're using...
I wonder how MythTV and other open-source applications handle it? Do they? Or is it all in the display values, so no-one has ever noticed it on anything other than tvheadend? If folks didn't see the fractions, they'd never know, so 'bad reception' would just be 'one of those things'... however... if it can be proven that integer frequencies improve things, then we have a symptom, cause and solution that no-one else has even spotted...
Just a thought.
Updated by Jaroslav Kysela over 9 years ago
I have nothing against the "work-arounds" in the frontend settings (hardware input tree), but it must be proven. I saw only speculations here.
By the way - you can edit the mux parameters and change frequency (set last three values to zero). The frequency changes up to 4Mhz received from the auto-discovery are ignored in the tvh code, so your value won't be overwritten.
Updated by Rob Rob over 9 years ago
Jaroslav Kysela wrote:
I have nothing against the "work-arounds" in the frontend settings (hardware input tree), but it must be proven. I saw only speculations here.
By the way - you can edit the mux parameters and change frequency (set last three values to zero). The frequency changes up to 4Mhz received from the auto-discovery are ignored in the tvh code, so your value won't be overwritten.
My report comes from a TBS6985 quad DVB-S2 card.
Tested with drivers from Luis Alves
https://github.com/ljalves/linux_media/wiki
(Latest 18th may, but also same behaviour noticed in at least last few revisions from 12 months+ ago)
Same behaviour in official TBS drivers that everyone seems to recommend against using.
The behaviour is repeatable without fail by simply running a scan on all muxes.
Waiting for scan to finish, then altering those muxes decimal point that haven't tuned correctly, be it .25/.50/.75 and round up or down to the nearest integer.
= tune straight away.
Out of 80 muxes, I may have say 5-6 muxes that have this problem where the decimal place is preventing services being scanned (of roughly 20 with a decimal place that do tune) no matter how many times I run the mux through for a scan "no data" is the result. Until those numbers after decimal place are removed.
The person who submitted this report has a Geniatech HDStar USB receiver vs my TBS6985
Updated by Rob Rob over 9 years ago
By the way - you can edit the mux parameters and change frequency (set last three values to zero). The frequency changes up to 4Mhz received from the auto-discovery are ignored in the tvh code, so your value won't be overwritten.
This is tbe method used to directly repeat the issue.
Updated by Jaroslav Kysela over 9 years ago
Rob Rob wrote:
By the way - you can edit the mux parameters and change frequency (set last three values to zero). The frequency changes up to 4Mhz received from the auto-discovery are ignored in the tvh code, so your value won't be overwritten.
This is tbe method used to directly repeat the issue.
Fine. Could you show me traces for the linuxdvb subsystem for both cases ? Including the continuity errors ? (Identical mux).
Updated by Jaroslav Kysela over 9 years ago
Rob Rob wrote:
Jaroslav Kysela wrote:
I have nothing against the "work-arounds" in the frontend settings (hardware input tree), but it must be proven. I saw only speculations here.
By the way - you can edit the mux parameters and change frequency (set last three values to zero). The frequency changes up to 4Mhz received from the auto-discovery are ignored in the tvh code, so your value won't be overwritten.
My report comes from a TBS6985 quad DVB-S2 card.
Tested with drivers from Luis Alves
https://github.com/ljalves/linux_media/wiki
(Latest 18th may, but also same behaviour noticed in at least last few revisions from 12 months+ ago)
Same behaviour in official TBS drivers that everyone seems to recommend against using.The behaviour is repeatable without fail by simply running a scan on all muxes.
Waiting for scan to finish, then altering those muxes decimal point that haven't tuned correctly, be it .25/.50/.75 and round up or down to the nearest integer. = tune straight away.
Out of 80 muxes, I may have say 5-6 muxes that have this problem where the decimal place is preventing services being scanned (of roughly 20 with a decimal place that do tune) no matter how many times I run the mux through for a scan "no data" is the result. Until those numbers after decimal place are removed.
Could you tell this to the driver's author ? It seems like that last three digits are handled wrongly.
The person who submitted this report has a Geniatech HDStar USB receiver vs my TBS6985
Probably same issue..
Updated by B C over 9 years ago
Are all your problem transponders on Eutelsat? So maybe it's simply a signal problem?
Updated by Stuart Lape over 9 years ago
B C wrote:
Are all your problem transponders on Eutelsat? So maybe it's simply a signal problem?
No it's not a signal problem, I have seen the transponders are shifted about 864MHz off so 12207V transponder scans shows up 11343V channels.
I have opened a GitHub issue at https://github.com/OpenELEC/OpenELEC.tv/issues/4195 since this could well be a kernel issue.
Updated by B C over 9 years ago
I would say you have a 22khz problem, so your LNB is not correctly put into high band mode. The offset is 850 mhz, the rest is what the pll locks.....