95 replies to this topic

[Tobbe]

hello

 

i have a new vu+ solo 4k with a TT3L10, the problem i have is that when i do a channel scan it only finds the dvb-t channels and all dvb-t2 channels is missing (pretty much all hd channels is gone)

i tried openvix too and it got same problem so it is likely a driver issue.

 

any idea what i can do to make it work?

the vuplus default image from vuplus themsevles can scan and find all channels oddly, and on openvix i was also able to make it work by copying over a working lamedb file.

 

so something must be broken in dvb drivers, any advice?

 

[Erik Slagter]

It this a single input DVB-C/DVB-T tuner? It seems VU+ have a fix for that in their drivers. But this version hasn't been pushed to our BSP, so we can't offer it. You could try install them yourself.

[Tobbe]

one cable goes in, it got two tuners that can be used independently and each support both dvb-c and dvb-t/t2

 

any pointers on how to get the drivers installed?

do i need to build my own image?

 

other images seems to have same problem

[Tobbe]

It this a single input DVB-C/DVB-T tuner? It seems VU+ have a fix for that in their drivers. But this version hasn't been pushed to our BSP, so we can't offer it. You could try install them yourself.

well... i don't think it is that easy.

i flashed openpli-6.0-rc-vusolo4k-20170707_usb.zip and as expected it only finds the dvb-t channels and no dvb-t2 channels at all.

i then tried copying over the working /etc/enigma2/lamedb that was produced by a scan on the vuplus default firmware image and i now have all channels, including the missing dvb-t2 HD channels that the scan can't find by itself.

 

so drivers work and can tune dvb-t2 but not find it when doing a scan for some odd reason.

advice?

[Tobbe]

i think i just found something, i noticed that the vuplus default image have PLP ID set to 001 by default when scanning, this seems to make a significant difference.

PLP ID set to 000 makes it impossible to find channels, setting it to 001 makes the channels show up on a scan.

 

what is PLP ID ? and why is it important?

[Tobbe]

after a bit of searching it looks like this is an old problem, see this post: https://forums.openp...ndpost&p=503316

i guess it was never fixed fully and that thread was also from Sweden, same as me.

[roadster]

I have the same problem with the Ultimo4K. The latest release of the standard VuPlus image partially fixes it but needs a complete scan to find the T2 channels. There is also a problem with the program data which is not being correctly read on the T2 channels and this in turn causes corruption if timers are set in the timers.xml file. The latest Blackhole updates are in a similar state. Some patches can be seen in recent Vuplus updates ( code.vuplus.com ) but I have no idea how these get incorporated in OpenPli.

[Huevos]

For a complete scan you just need a proper terrestrial.xml file and add the right parameters for your location.

 

BTW, satfinder needs fixing to display PLP ID. See here: https://github.com/O...b4c98c05df56b58

[athoik]

I created a PR: https://github.com/O...igma2/pull/1036

Thanks!

[WanWizard]

Merged by littlesat yesterday.

[Erik Slagter]

Shouldn't this have been in de rc branch, now it can't be in the rc.

[Huevos]

Can't you just cherry pick it from the develop branch?

 

What branch are we supposed to do a PR against when submitting code?

Edited by Huevos, 12 July 2017 - 21:04.

[athoik]

Bug-fixes should go on RC-6 and merged on Develop.

New features should only go on Develop.

Obviously that is more "bug-fix" rather than new feature.

Cherry-picking in that scenario what problem causes? Double commits in Develop?

[Huevos]

Bug-fixes[...]

Cherry-picking in that scenario what problem causes? Double commits in Develop?

Yes, you would get a double commit in the commit history, but no merge conflict.

[Huevos]

Or just revert it in "develop" and commit to the correct branch.

 

I guess it really is about how fussy you are about how the commit history looks.

Edited by Huevos, 12 July 2017 - 21:24.

[WanWizard]

Very.

[WanWizard]

Problem is that repairing it properly isn't that easy as well, and involves the "not done" trick of rewriting history. Everything should be how it is supposed to be now. You will have to update your local clone.

 

PR strategy is:

- features always go into Develop

- fixes on R/C have to go into the R/C branch, and will be merged back into Develop

- fixes on Release should be avoided at all costs, but if needed, a PR from a hotfix branch should go to both the Release branch and Develop (there is no merge back from Release).

 

This basically follows the git-flow model.

[Huevos]

"Rewriting history", a.k.a. "forced push" breaks everyone's local copy. Also break build server and requires a PR bump. Without a PR bump the build env needs trashing and starting from scratch.

[Erik Slagter]

Very.

LOL. Yeah, +1 (at least).

[Erik Slagter]

Merged by littlesat yesterday.

 

Shouldn't this have been in de rc branch, now it can't be in the rc.

 

Anyway, we're drifting here.

 

If we consider this a bug fix that needs to be in the release, it must be reverted and applied in rc-6.0.

 

And Littlesat should learn to be a bit less merge-button-trigger-happy