104 replies to this topic

[WanWizard]

You still have that when you have two or three recordings running on the same root tuner?

 

I think you may need to time your zap responses, it takes the tuner already about a second to tune, and it takes the same time to sync both audio and video (audio starts quicker than video). Set the zap mode to "Black screen" so you can see it more clearly.

[-M-]

4-5seconds is what I think it is for me (without the fix), however by do a videorecording and check time in video editor. I got 7 seconds, but did it only for two zaps. OpenVix was 2.0 seconds. With the fix for OpenPLi it was 1 to 2 seconds. This between two of the channels I have selected to do this test on (both scrambled). I have also of course done zapping between many other channels and with this fix it is fast - every time (atleast yesterday night when I did this). Note that zapping between services on the same transponder goes quicker.

 

Well, the exact time doesn't mattar. What matter is that something strange is going on in the system. Printing in front LCD should not influence the main program. It should be carry out asynchronous and not steal time from main action.

[-M-]

Oops, sorry WanWizard. Now I see your last question.

 

Please, can you define root and leaf tuner? I'm not exactly sure about what it mean. I have one FBC S2X (BCM45308X).

[WanWizard]

An FBC complex consists of two inputs, two root tuners, and six leaf tuners.

 

In SCR (Unicable) mode, only one input is used (unless directly connected to a wideband LNB), and all eight tuners work independently.

In legacy (DisecqC) mode, it emulates a twin-tuner using the two inputs and the two root tuners, and uses the leaf tuners as dynamically looped through.

 

In terms of tuner letters, the first two are the roots, so if you have two FBC modules in your Duo 4K (like I have), the root tuners are A and B (first FBC module) and I and J (second FBC module).

 

Note that zapping between services on the same transponder goes quicker.

 

I have noticed that too.

 

What matter is that something strange is going on in the system. Printing in front LCD should not influence the main program. It should be carry out asynchronous and not steal time from main action.

 

The problem I have with this:

• Even if lcd4linux is enabled, it doesn't do anything since no lcd definitions are enabled by default, the information on the display comes from a display xml in the selected skin.
• If lcd4linux is to blame, why is the problem not gone when you remove lcd4linux and reboot the box? Something that isn't there can't be of influence?

[WanWizard]

Reading my response back, and thinking about this: I had a discussion with team mate Erik about this the other day, and he doesn't have these issues. But he has an SCR setup. So what if this is DiseqC related?

 

Because I also notice that when zapping it takes a while before the SNR% in the skin is updated from 0% to whatever the reception is.

[-M-]

Yes the problem cannot be blame on the lcd4linux, but something that it, in some way, switch on/off in main software. Or some random strange bug.

 

I tested to do zap while recording in progress (with the fix)...
Rec on demod A. Zap demod B: OK (quick)
Rec on demod A and B. Zap demod C: OK (quick)

With the fix it seems to be alright also on other demods. I actually use all 8 demods, however I didn't keep track of transponders in use and couldn't do the exact same zap test (right now only two uniLNB signals to the box).
 

PS. I don't have external switches, but since Universal-LNB it is DiseqC commands to LNB.

 

Edit: Wonder how it would be on an image which never have had lcd4linux plugin installed.

Edited by -M-, 5 March 2019 - 16:43.

[WanWizard]

I still don't see what the fix is.

 

There is no relation between lcd4linux and zapping, and removing a proper package build from source doesn't leave any residue, so I also don't see how something that isn't there can have any effect.

 

Edit: Wonder how it would be on an image which never have had lcd4linux plugin installed.

 

I'll let you know, currently building one.

[-M-]

Sorry for what I wrote about universal LNB and DiseqC. Short-circuit in my head (or overload). They don't have it, they use voltage and tone to select quadrant. So no DiseqC here.

[-M-]

I have tested with a new image without lcd4linux. After fresh install it is quick zapping. 1-2 seconds (however one time 3 seconds).

 

PS. Well I'm new to this system... What I did was to remove the lcd4linux row in the image bb file. I also looked in the plugins menu in the box and no lcd4linux. I didn't restore any settings and did new channel search. To keep it as fresh as possible.

 

PS2. Some detail about zapping and time (for two zappings): I notice that from that the info box show the new channel. It takes 0.1 - 1.0 second for the resulution to show up (in the info box). Then it takes 1.0 seconds for the video to show. I guess the 0.1 - 1.0 is the actual tuning time. Little unsure about the time from key press until info box react, but seems to be very short. I zap between two and the same channels.

[WanWizard]

Good, so I don't have to do that anymore.

[Erik Slagter]

Indeed, lcd4linux influencing the tuning process is not possible. I can only imagine that the display of an icon is delayed because of a harddisk needing spin up (or similar) that blocking the main thread and who knows part of the tuning is also run in the main thread. In that case the cause is not lcd4linux but the delay.

 

With my SCR setup I very seldomly see a delay in tuning. So it's not completely absent but rare.

 

It's a mistake to think that using SCR is different than a DiSEqC setup, because SCR uses almost DiSEqC signalling. So if anything would be broken there, in the drivers or in the hardware, both would suffer. What does make a difference is that SCR participating tuners remain on the same frequency, all of the time. The SCR switch or LNB changes the oscillator to the mixer so the center frequency of the transponder is found at the frequency the tuner is set to. That might make the difference.

[Erik Slagter]

Just checked a complete round on my favourites, all of them are LOCKed witin a second. Not yet moving picture, because of the decryption and the a/v sync, but that's another story.

Let's establish what's the problem for everybody. Lack of tuning or lack of decryption!

[Trial]

Hi,

there is an option in LCD4Linux to mirror your GUI and this slows down the box.

 

LCD4Linux is used to give boxes without a display the possibility to have something similar for instance by using an old smart phone or tablet.

 

ciao

[WanWizard]

That is logical, understandable.

 

But by default lcd4linux is installed but doesn't do anything. I've removed it, and I still have the LCD info I always have.

 

I also don't have 5-7 sec zap times, only occasionally, and when that happens, it is usually when several tuners are busy with recordings.

 

So I think you are on to something, there seem to be two different issues related to zap times, and this particular issue might be related to a users personal lcd4linux configuration.

[Abu Baniaz]

I am not getting the 5-7 second zap times using PLI Dev image. I am using SCR LNB though. Can't understand why it seems slower than Vix.

I'll see if I can test a universal LNB on Thursday or weekend.

[alias haha]

LCD4linux slows the zapping (zero signal) if you go from a 19.2 channel to a 23.5 channel, if you disable lcd4linux then is this problem gone, i have tested this with 5 different image builders, al have the same problem with the lcd4linux plugin.

Even if you swith everyting off in the plugin, that doesn't matter.

Edited by alias haha, 6 March 2019 - 07:02.

[Taykun345]

I will also test on my Duo4k.

[WanWizard]

I am not getting the 5-7 second zap times using PLI Dev image. I am using SCR LNB though. Can't understand why it seems slower than Vix.

 

In general, neither do I. I only see it only sometimes, and then only when I have a few concurrent recordings active.

[-M-]

First let me tell you that another problem I had is also gone with this fix. Scrambling packets in the beginning of recorded ts files.

Now over to a test I did...

- Pre state: an image which never have had lcd4linux installed.
-> zap is quick
# opkg install png-util_1.0-r0_armv7ahf-neon.ipk
# opkg install pydpflib_0.14\+git2\+aa26739-r0_armv7ahf-neon.ipk
# opkg install python-imaging_1.1.7-r5_armv7ahf-neon.ipk
# opkg install python-mutagen_1.38-r1_armv7ahf-neon.ipk

# opkg install python-pyusb_1.0.0b2-r0_armv7ahf-neon.ipk
# opkg install python-simplejson_3.10.0-r0_armv7ahf-neon.ipk
# opkg install enigma2-plugin-extensions-lcd4linux_5.0-r4-29\+6aef8a4-r0_armv7ahf-neon.ipk
- Reboot
- Menu Plugins lcd4linux; enable on
-> zap is slow
- Remove lcd4linux (using Menu - Plugins...)
-> zap is slow
- Reboot
-> zap is quick

Okay so this is good. However someone wrote that after remove it, the problem still exist. Wonder if that was without a reboot.

[WanWizard]

That is logical, as long as you don't restart Enigma, the code is still loading in Python memory, and active.