48 replies to this topic

[kurben]

You should be able to auto tune anyway. Should not need code rate. Just use predefined transponder and select the channel/frequency. That comes from terrestrial.xml and doesn't contain code rate at all. The tuner should work it out.

If it could do that then I would have no problem to tune to a mux with those code rates. But it wont. It could also be a completly diffrent bug that is involved but the missing code rates are the only cause I have found so far.
The Dvb-T2 mux with a supported code rate tunes just fine.

[kurben]

Maybe you can try out the patch if you make your own image. I cannot check it by myself if it works.
You can when you select dvb-t2 in the scan menu the option 3/5 and 4/5.

I would happily test this patch but I have no skills or possibility to build my own image.

But I will eventually setup a build enviroment in Ubuntu and start compile my own images. But that is far away in the future...

[Huevos]

The problem seems to be that those code rates your broadcaster is using are not part of the dvb standard as is shown in the document I posted.

[kurben]

The problem seems to be that those code rates your broadcaster is using are not part of the dvb standard as is shown in the document I posted.

But according to wikipedia they are, I do not think that Sweden has its own system, Sweden is also one of the countries that are involved in the development of the dvb standard and also one of the first to adopt the Dvb-T2 standard.

Either way, the fact that the code rates exists in the sat and cable parts but not in the terrestial part indicates more to the option that they have not been updated to the last standard.

[WTE]

 

Maybe you can try out the patch if you make your own image. I cannot check it by myself if it works.
You can when you select dvb-t2 in the scan menu the option 3/5 and 4/5.

I would happily test this patch but I have no skills or possibility to build my own image.

But I will eventually setup a build enviroment in Ubuntu and start compile my own images. But that is far away in the future...

 

 

Which box?

[kurben]

 

 

Maybe you can try out the patch if you make your own image. I cannot check it by myself if it works.
You can when you select dvb-t2 in the scan menu the option 3/5 and 4/5.

I would happily test this patch but I have no skills or possibility to build my own image.

But I will eventually setup a build enviroment in Ubuntu and start compile my own images. But that is far away in the future...

 

 

Which box?

 

 

VU+ SoloSE v2

[Huevos]

 

The problem seems to be that those code rates your broadcaster is using are not part of the dvb standard as is shown in the document I posted.

But according to wikipedia they are,

Anyone can edit Wikipedia. You really need an official source. If you can get a dump of the NIT table with DVB Snoop we will be able to see what number the broadcaster uses for that code rate.

[kurben]

I have now tested with a USB DVB-T2 tuner (PCTV 290e ) . This tuner can tune the 730 mhz mux without problems. That means that the bug is not in Enigma2 code but rather in the Vu+ driver for the built in tuner.

I have the new Vu+ SoloSe v2 with the new Dual DVB-T2 tuners. I will once again contact Vu+ and probably not get en answer as the two other times I have done that....

 

 

But at least we now know the problem lies in the Vu+ drivers and not the actual code for Enigma2...

[kurben]

ok, more update regarding this bug and perhaps more confusing...

 

I tried the Openmultiboot feature and installed some more diffrent images and found that OpenAtv 5.1 (Latest version) can tune channel 53 ! with DVB-T2. 

But not only is some images missing the possibility to tune the channel 53, they also does not work with decoding using my Viaccess CAM in the CI slot.

 

 

I tried these images:

OpenPli 4.0 2015-08-29 (No tune channel 53, Working CI/CAM)

Open Black Hole 0.1 (No tune channel 53, Working CI/CAM)

OpenATV 5.1 (Tune working on Channel 53, NO working CI/CAM)

Black Hole 2.1.7 (No tune channel 53, NO working CI/CAM)

 

 

Strange is it? I then took the terrestial.xml file from OpenAtv 5.1 and loaded into OpenPli 4.0 to see if that would change something, but no, same result..

So what is OpenATV 5.1 doing right in the tuning? And what is OpenPli doing right in the CI/CAM ?

[Huevos]

Try OpenViX too.

 

If you tried OpenATV there is no FEC setting in the terrestrial.xml file for channel 53 Europe, as such a setting would imply FEC is fixed throughout Europe.

[kurben]

I have now tried OpenVix (latest) and it can not tune to channel 53, but the CI/CAM is working.
I also tried the latest Vu+ factory image and that works with channel 53 and also CI/CAM.

So the tuning problem is not in the drivers from vu+ since there image works. The only two images that can tune the channel 53 is vu+ original and OpenAtv.

[Erik Slagter]

It seems ViX has other drivers than VU+ supplies to us.

[Rob van der Does]

I've said it before: PLi is (at least as far as I'm aware) the only image builder who uses the 'normal' drivers; all others use the GLES-drivers.
So there can indeed be differences between PLi and others at driver level.

[Erik Slagter]

Ask VU+ to provide us with the "better" (?) drivers.

[kurben]

I have noticed one strange thing that I will try to film. When using the automatic tuning function on VU+ factory image and also the OpenATV image (The only two ones that can tune to channel 53) the tuning does not find anything when it reaches channel 53, but in the end of the process, around 800 mhz and above or 96% of the scanning. It jumps back to a few channels and rescans them, among those channels is my problem channel 53 at 730mhz. 

If I manually select only channel 53 and set everything to Auto, nothing is found. Very strange, the autoscan has some other special function in the end of the scan. As I said I will try to film this so that you can see what I am rambling about...

[Erik Slagter]

Do you have "network scanning" active?

[kurben]

Yes always.

[Rob van der Does]

Ask VU+ to provide us with the "better" (?) drivers.

It's completely up to you which drivers you use, as it is for all image builders.
But if you made yourself dependant on an external party (the factory), you should ask them to supply the GLES-drivers, as well as the required changes to use them.

[Erik Slagter]

Yes always.

Then that is the explanation.

Edited by Erik Slagter, 1 September 2015 - 14:31.

[Erik Slagter]

 

Ask VU+ to provide us with the "better" (?) drivers.

It's completely up to you which drivers you use, as it is for all image builders.
But if you made yourself dependant on an external party (the factory), you should ask them to supply the GLES-drivers, as well as the required changes to use them.

I don't understand at all why we should need GLES enabled drivers if enigma doesn't use it...