Tvheadend

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,

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.

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.

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.

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.

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.

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.

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

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.

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).

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..

Are all your problem transponders on Eutelsat? So maybe it's simply a signal problem?

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.

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.....