45 replies to this topic

[Taapat]

On my UE 4K use my oscam version (latest svn + small patch): https://github.com/T...cam-demux-patch

I have not observed any problems with oscam.

 

Thefore today for test I tried on develop image install enigma2-plugin-softcams-oscam-emu from feed.

I get an error:

root@gbue4k:/var/volatile/tmp# opkg install --download-only enigma2-plugin-softcams-oscam-emu


Collected errors:
 * Solver encountered 1 problem(s):
 * Problem 1/1:
 *   - nothing provides zgemma-libs-3798mv200 >= 1.0 needed by enigma2-plugin-softcams-oscam-emu-git1550+c3397c9-r0.0.cortexa15hf-neon-vfpv4
 * 
 * Solution 1:
 *   - do not ask to install a package providing enigma2-plugin-softcams-oscam-emu

Looks like there's a problem here with depensies or with arch to compile oscam-emu for non zgemma boxes.

 

U.P.D.

The same error for enigma2-plugin-softcams-oscam:

root@gbue4k:~# opkg install enigma2-plugin-softcams-oscam


Collected errors:
 * Solver encountered 1 problem(s):
 * Problem 1/1:
 *   - nothing provides zgemma-libs-3798mv200 >= 1.0 needed by enigma2-plugin-softcams-oscam-git10352+739a61f-r0.0.cortexa15hf-neon-vfpv4
 * 
 * Solution 1:
 *   - do not ask to install a package providing enigma2-plugin-softcams-oscam

Edited by Taapat, 28 December 2018 - 15:26.

[WanWizard]

Known problem, both in develop and in rc.

Zgemma-libs-3798mv200 is in the h9 and i55plus bsp, and it introduces glibc 2.27. Bitbake knows this, and changes dependencies, which impacts all cortexa15 packages.

 

Erik and I are busy with it.

 

We tried to work around it by building the i55plus and h9 first, but since a few days both builds fail on kodi, which triggers a retry, which in turn makes them build last again...

[Taapat]

I assume that zajkas112 forced installed oscam-emu from feed without this library, and therefore he has these crashes.

Perhaps she changes enough in glibc to oscam not work without her.

Edited by Taapat, 28 December 2018 - 15:40.

[WanWizard]

There is no real dependency, so that can't be the case. 

 

The problem is purely a bitbake thing, and something zgemma has to fix in their BSP.

 

The UE4k builds, and inserts a "libc.s0.6 (>= 2.25)" dependency, which is ok. Then the H9 builds, it sees that zgemma-libs introduces libc.so.6 (2.27), so it changes the dependency in the packages from "libc" to "zgemma-libs". Which is not a problem for MACHINE packages, but a big problem for ARCH packages, since the other machines with that same ARCH don't have this package.

[ims]

I had same problem on all machines with oscam on my homebuilds ... I used -c cleanall -f for oscam, build again and all is ok now ... No matter how is builded H9 ... I am building in loop "e4hd h9 vs1500 ..." and problem had e4hd and vs1500 too

Edited by ims, 28 December 2018 - 16:01.

[zajkas112]

Hello good news here All is fine and working !!!

Today a tryed to flash  with pur E2  but it is suck in unicable II initial config and crash in  first 5 minutes after  flash. 

So back to openPLi  -> 6.2 24/12/2018 image. and work like a charm .... oscam-emu not crashing. I watched 3 channels in same time  and no freeze no instability procesor about 47 degree.

Thank you for support 

Now other  question  what is about to cut hdmi in stanby  because  I use monitor without remote and night lightening  monitor is not fun  for me.

 

Thank  you 

 

PS Team had revolute account ? For a small donation from me.

[WanWizard]

PS Team had revolute account ? For a small donation from me.

 

Much appeciated. We use paypal, see the button at the top-right on this page.

[Rob van der Does]

Now other  question  what is about to cut hdmi in stanby  because  I use monitor without remote and night lightening  monitor is not fun  for me.

This is actually a problem with many (all??)E2-STB's. This also hampers (the auto-switching of) HDMI-switches.

Edited by Rob van der Does, 29 December 2018 - 08:45.

[Erik Slagter]

AFAIK it's only present on GigaBlue receivers. My VU+ receivers switch off HDMI in standby like expected.

[ims]

Worse is, when it is partialy active (powered) in deep standy !  I have manual HDMI switch 3:1 with very easy "auto" switch (when is 5V presented, imho).

Pluged H7, H9 and ninopro. All boxes are in deepstandby. Led on HDMI switch still shining on corresponding input, when is pluged H9 or osninoplus. Only H7 has in deep standby turned off 5V in HDHM.

[Rob van der Does]

AFAIK it's only present on GigaBlue receivers. My VU+ receivers switch off HDMI in standby like expected.

All my VU's keep HDMI activated. They always have.
In my case it's easy recognisable by the LED's on my HDMI-switch (and as a result the switch doesn't 'auto-switch').
And I'm talking about standby; in deep-standby they do switch off, as expected.

Edited by Rob van der Does, 29 December 2018 - 16:34.

[WanWizard]

I wouldn't be suprised if that is part of the protocol, i.e. it is switched on/off after a handshake of some sort. And if "cheap" switches don't do any of that.

 

On my el-cheapo the led stays on as well, but it does switch to another input if I switch on a second box.

[WanWizard]

Correction: I've checked the specs, the 5V should be live as long as the device is powered (which is the case in standby I guess). It is used to power an I2C bus at the remote end.

[ims]

For stanby - it should be active due HDMI-CEC. But in deep standby ?

 

My 3rd switch (both two previous with rc and pip was damaged very soon) is very easy ... cca €6, without power. It should to know, where is signal (may be, where is 5V only), but when are ports still powered, I must toggle manually...

[WanWizard]

For stanby - it should be active due HDMI-CEC. But in deep standby ?

 

It should be off in deep standby (I really hate that, why not call this "off" so everyone knows what it is about).

[ims]

Because f.eg. zgemma is "off", when you push and release power switch and then there is no voltage in box, but in deepstanby it has powered some parts in box... with active WOL on H9 shining red logo, is powered NIC, works receiver iR.

As I saw somewhere in code, some boxes had not deepstandby, only total power off...?

 

But important is, if producers will comply with the basic rules...

[WanWizard]

There will never be a total power off (unless you have a box with a power switch on the back and you use that), the front controller is always powered so it can respond to the power button, the remote, or the countdown timer (used by wakeup timers).

[Erik Slagter]

 

AFAIK it's only present on GigaBlue receivers. My VU+ receivers switch off HDMI in standby like expected.

All my VU's keep HDMI activated. They always have.
In my case it's easy recognisable by the LED's on my HDMI-switch (and as a result the switch doesn't 'auto-switch').
And I'm talking about standby; in deep-standby they do switch off, as expected.

You're talking of another phenomenon that I do. I was talking of sending a valid video signal. The Gigablue receivers keep sending a valid video signal. The VU+ receivers shut down the transceivers.

 

If they only keep the power supply on, that's another story. I guess there could be situations where that is preferrable.

 

Also a HDMI switch should not rely on that pin, but assert a valid video signal. But AFAIK none of them do.

[Rob van der Does]

Also a HDMI switch should not rely on that pin, but assert a valid video signal. But AFAIK none of them do.

I'm not sure what signal/voltage/pin my HDMI-switch 'listens' to, but using any VU-STB the 'active-LED' on the switch remains 'on'.
And that is what prevents the switch from 'auto switching' to an other device.
And my HDMI-switch isn't a cheap one, far from it....

[Erik Slagter]

Yes, as said, they're all looking at the +5 voltage, which, according to the standard, should always remain active. Instead they should look at the sync, but apparently that's difficult and I've never seen a HDMI switch do that. For that the switch must actually decode the TMDS signal and determine whether a valid, constant sync is sent.

 

I prefer using monitors with multiple inputs, for the simple fact that a monitor can do this trick, where the HDMI switch fails at.

Edited by Erik Slagter, 31 December 2018 - 13:08.