108 replies to this topic

[littlesat]

I'm convinced from the technical point of view this should not be required at all.... I think the best way to go is point manufactures that suffer from this to fix this in their drivers...

Question from my side, why do we "suddenly" need this. Where (cable network + boxes) do we need this?

Edited by littlesat, 9 October 2016 - 10:38.

[dAF2000]

It has nothing to do with drivers. The frequency is sub-MHz and the UI only allows MHz's to be entered. So, the UI is "wrong" here. Also, in the unlikely case the provider uses frequencies like 400.1, 400.2, 400.3 there is no other solution.

[littlesat]

dAF2000.... I would expect that when you are 500 KHz off the center frequency the tuner simply should tune it due to AFC... and therefor it should not be required at all.... But is seems some dirver tuners do not have this "smartness".... 

 

And then someone discovered that you can adjust it (via xml or change in code) manually... instead of trying to improve these drivers...

Edited by littlesat, 9 October 2016 - 10:54.

[dAF2000]

dAF2000.... I would expect that when you are 500 KHz off the center frequency the tuner simply should tune it due to AFC... and therefor it should not be required at all.... But is seems some dirver tuners do not have this "smartness".... 

 

And then someone discovered that you can adjust it (via xml or change in code) manually... instead of trying to improve these drivers...

 

I see. That would work if the AFC can handle a frequency difference of 500kHz. I don't know if it does; it may be hardware limited.

[littlesat]

My question is why this requirement suddenly appears after years.... is there one type of box/tuner that suddenly suffers from this? Is it suddenly one kind of cable provider does weird stuff?

 

When it is tuner related I prefer we should try to convince the manufacturer first -before- we blind headed "hack" the E2 code....

 

When it is really cable provider related and (almost) all boxes and tuner suffer from this, then we should go for a solution in E2...

As far I know and try the tuners must cover these 500 MHz....

Edited by littlesat, 9 October 2016 - 11:34.

[littlesat]

I did some googling...

 

https://www.spycat.d...TV-Kabel-Tuner/ -> AFC range 500 KHz..../sync 900 KHz...

 

But here I see an example with "just" 150 KHz...

 

http://www.fujitsu.c...tasheet_DVB.pdf

 

For DVB-S this parameter is easy to find... for DVB-C as far I search I could not find any indication...

 

Adding a . into this parameter is "challenging..." as this was never done before in E2 for entering a frequency... I suggest enterring it as 100-st of KHz and displaying it xxx.x by giving that "field" a special mode.... (add parameter for decimal point).

 

If we have a lot of tuners that are following the second spec above, then this might be a requirement...

 

As soon I have time I will add a decimal point to integer config... by adding a parameter decimalpoint.... default zero and one is one digit behind the point... )

Edited by littlesat, 9 October 2016 - 13:19.

[littlesat]

Mmmm adding a decimal point is somehow challenging due to this code...

 

https://github.com/O...nents/config.py

Edited by littlesat, 9 October 2016 - 13:23.

[littlesat]

But we have configFloat... 

 

e.g.

 

nim.turningspeedV = ConfigFloat(default = [1,7], limits = [(0,9),(0,9)])

 

Should be a better plan...

[Huevos]

I'm afraid it might be better that they change the tuners config in the drivers so they catch-up within 1 MHz... But we cannot change th drivers
But could you also offer a commit request to us?

Well if that is what you think why is DVB-T in kHz, i.e. already 6 figures? Same hybrid tuners, and same step size.

[littlesat]

Maybe we should also change it there MHz....

[Huevos]

I'm convinced from the technical point of view this should not be required at all.... I think the best way to go is point manufactures that suffer from this to fix this in their drivers...

Question from my side, why do we "suddenly" need this. Where (cable network + boxes) do we need this?

Yeah right, lol.

 

When Abu first requested this to me about a year ago I was of the same opinion that it was not necessary, but after watching the various threads on our forum over the last 12 months I am absolutely sure this problem is not related to a particular brand or manufacturer and is genuinely a case of the step size being too large. Cable has 8 MHz and smaller spacing between transport streams, and symbol rates in the 6500 range. A 1 MHz step is more than 10% of the typical spacing. Compare this to satellite where typical spacing between transponders is 30 MHz, a 1 MHz step is only around 3% of the spacing. Also, this is nothing to do with drivers, it is down to the hardware how loose the tuner is.

 

Also, why would PLi not want to give their users proper control over their equipment even if the equipment is a bit suspect? All that is going to do is make PLi's users turn to other images that do allow them to tune the channels they want to watch.

Edited by Huevos, 9 October 2016 - 16:11.

[littlesat]

I do not say it is not necessary. I only say it could be made differently

[Huevos]

I do not say it is not necessary. I only say it could be made differently

Like Unicable II.

 

BTW, you always used to accept code from me in the past (user defined transponders in Manual scan and satfinder, DVB-T2/C in satfinder, tuner selection in satfinder, bug fixes, blindscan, etc, etc) but now it seems impossible to get even the simplest commits to be accepted. Should I not bother in future?

Edited by Huevos, 9 October 2016 - 16:32.

[littlesat]

Unicable-2 is in progress.... the available patch was not done....

We're only considering here to keep it in MHz and use the ConfigFloat class instead and use e.g one additional digit. And not change it to KHz and add mandatory digits. This is not about blindly merges, this is about discussing how to make it the best... and sure I can accept, but when I see something can be easily improved ....?

Edited by littlesat, 9 October 2016 - 17:06.

[Huevos]

Well one digit is not enough. typical values are

 

0.0,

0.125,

0.25,

0.375,

0.5,

0.625,

0.75,

0.875.

 

If the broadcasters thought rounding to the nearest 0.1 was sufficient they would use these values in the DVB SI tables. If PLi want to ignore the DVB standards that is up to them. As usual PLi know best.

[littlesat]

Good point....

Are you capable of trying it? As far I can see tuners should catch within 150 KHz... But u less this with ConfigFloat also 3 digits could be added....

But which cable network(s) are using this??

Edited by littlesat, 9 October 2016 - 19:28.

[Huevos]

Virgin Media (UK). Ziggo (NL) and various other NL cable networks. The thing with cable is it doesn't follow a strict band plan like terrestrial.

[Huevos]

TBH it doesn't make sense using configfloat because behind the scenes this value is an int. So would be just converting for the sake of it.

[littlesat]

With Ziggo NL I have no issue here with ET10K and VU Solo4K... so still I want to know which tuners do have issues here...

 

And sorry it makes still sense to use the ConfigFloat as this allows to enter the frequency in MHz with a decimal point.... No "real" converting required... Basically this config returns a list with the number before and after the decimal point. You can calculate the result integer frequency via e.g. (pseudo code) frequency = config.value[0] * 1000000 + config.value[1] * 1000.... -or with basically a double conversion- frequency = int(config.getfloat * 1000000)....

 

I also think this will simplify the patch and in addition the frequency can be kept in MHz as is SHOULD be...

 

And we could also consider to allign DVB-T to this...

Edited by littlesat, 10 October 2016 - 06:58.

[Abu Baniaz]

In the video I uploaded, receiver being used was a Solo 4K with a twin hybrid tuner. There are some areas with "complete" frequencies, unfortunately, I'm not in one of those.

Important thing is that the end user MUST be able to specify the exact frequency to scan. In my view, it does not matter whether they enter 370750 kHz or 370.750 MHz. Three decimal places will be ideal.

If displaying values in MHz is of utmost importance, the service information and scanning stage will also need adapting. They were in kHz last time I checked.