1177 replies to this topic

[WanWizard]

If you would have spent the time you have wasted with some impatient guy on coding instead, you could have gained world dominance by now.

 

Lol, you may have a point here... Us geeks fall into this trap way to often...

[WanWizard]

I don't understand how a standard functionality like GStreamer is considered a second class feature.

If we dont care about GStreamer we should not include it in standard image.

It should be on feeds, optionally installed.

 

I think is it a bit less black and white than this.

 

I do think that, moving forward, we need IPTV/streaming media support. But we need it end-to-end, gstreamer is just the technical base layer.

There is still a long way to go between the current E2 functionality and something rivalling the Kodi's of this world...

[toura8]

Hi evrybody,

I am looking for a good image for IPTV on my ET8500. Could you tell me please, which is the best (openpli, openvix,...). I know that we will never get openpli5 in moths, so any other image with the last gstreamers and looping functionalities is welcome.

[babsy98]

use openATV 6.0

[toura8]

use openATV 6.0

Thank you my friend

[toura8]

use openATV 6.0

Unfortunately the OpenATV6 is not available for this receiver, so the problem is still open unless Openpli team makes us a pleasant surprise 

Edited by toura8, 25 January 2017 - 21:23.

[Panther-6]

 

use openATV 6.0

Unfortunately the OpenATV6 is not available for this receiver, so the problem is still open unless Openpli team makes us a pleasant surprise 

 

@toura8

There is no chance for OpenPli-5 to come out in the next centuries. Perhaps our children or even their children will see OpenPli-5 coming out. You can take OpenATV 5.3 or 6.0 instead for Xtrend ET8500. It is working fine.

[littlesat]

OpenPLi 5 will come out... the only question is when.... In between I think I feed some trolls again....

[SpaceRat]

[Panther-6]

I am not a troll, I am only telling the truth. I am speaking for about 2 million people here, who are waiting for OpenPli-5 for decades now...

[WanWizard]

I believe I have been quite open and honest about the situation we are in, and the effort that is being put in by people to get us out the the hole we're currently in. If you can not understand and appreciate that, sorry.

 

If it bothers you so much, and you are convinced of your version of the truth, why don't you pack your bags and move elsewhere then, "Trump-6"?

 

That is clearly a win-win for both you and all other forum members.

[mrvica]

for people who own old boxes (like me), PLi5 is not better than PLi4 especially for playing multimedia files, for watching TV I don´t see any difference between them so you can stick with 4

[Erik Slagter]

Actually for most users (which would then be 2000 million users, in the same way panther-6 counts), there won't change anything moving from 4 to 5. Only people that are anxious to try IPtv (and I use the word "try" on purpuse here, because we cannot give a single guarantee in this respect), will note a difference. *EDIT* and the ones having h265 media

Edited by Erik Slagter, 26 January 2017 - 18:33.

[SpaceRat]

Actually for most users (which would then be 2000 million users, in the same way panther-6 counts),

I did some quick calculations ...

... and got 2396.9384673486 trillion people as a first rough estimate.

[WanWizard]

[SpaceRat]

Hmmm ....

WARNING: libpam-1.3.0-r5 do_pam_sanity: Building libpam but 'pam' isn't in DISTRO_FEATURES, PAM won't work correctly

And I notice OpenPLi 5.0 is going to use opkg 0.3.x
That will f*ck up the user's boxes whenever you bump busybox later. It will also mess around when updating any services (Whenever update-rc.d is involved).

[WanWizard]

A new release will mean a flash, you will not be able do an "opkg upgrade" from 4 to 5. So I don't see that being a problem?

[Erik Slagter]

I think it will need fixing anyway.

[SpaceRat]

A new release will mean a flash, you will not be able do an "opkg upgrade" from 4 to 5. So I don't see that being a problem?

I don't mean between 4.0 and 5.0, but during the lifetime of 5.0.

opkg 0.3.x is massively borked, it can not upgrade itself, packages with stopped services or busybox.
One of the changed between opkg 0.2.x and 0.3.x was, that prerm and preinst actions are now actually executed (They weren't in 0.2.x!) and their return code is checked.

Stopping an already stopped service using
/etc/init.d/<service> stop
returns 1/Fail for no apparent reason and as this call exists in every service's prerm-Script, opkg won't be able to remove or upgrade any stopped service.

It also executes prerm postrm preinst and postinst in wrong order:
1. prerm
2. preinst
3. postrm
4. postinst
instead of
1. prerm
2. postrm
3. preinst
4. postinst
so for many packages the postrm actions will fuck up the installation progress made in preinst.

For busybox, the wrong order and the suddenly implemented evaluation of return codes interrupts busybox installation just at the very moment when all links are gone -> image destroyed.

I strongly suggest to return to opkg 0.2.x or upgrade to apt (Dream did for a reason!) or at least have a look at these patches:
https://raw.githubus...orkaround.patch
https://raw.githubus..._nonfatal.patch
(Note: That patch should read 0.3.1_make_insane_checks_nonfatal.patch)

There is another quirk (Also fixed by the second patch):
opkg install nonexistant-package existant-package1 existant-package2 existant-package3 existant-package4
will install nothing, while opkg 0.2.x would have installed existant-package1 existant-package2 existant-package3 existant-package4.

That will mess up re-flashs with settings restore:
Assuming the user has installed any package from .ipk or that was removed from feed later, no plugins will be re-installed from your saved plugins list.
With the patch (by atvcaptain), opkg will install those packages that exist and simply skip the ones that don't.

The other patches were made by me.

Edited by SpaceRat, 26 January 2017 - 19:42.

[betacentauri]

I have reported the problem with opkg and many issues were fixed by oe devs. PLi 5 uses an oe version where e.g. upgrade of daemon package work again.