67 replies to this topic

[MastaG]

Hi samsamsam,

 

I've been making some recipes for building the dependencies required for your IPTV Player plugin:

See:

https://github.com/M...s-iptvplayer.bb

https://github.com/M...dl/hlsdl_git.bb

https://github.com/M.../f4mdump_git.bb

https://github.com/M...ubparser_git.bb

https://github.com/M...t-ifdsrc_git.bb

https://github.com/M...ir/lsdir_git.bb

 

This way, the startup wizard doesn't have to download any files from your server.

Also half of them don't download correctly due to difference version of openssl used in our release of OpenEmbedded.

 

The above ones all pass now, but I can't seem to find your modified sources for rtmpdump and duk.

duk will correctly download from your server and works OK, but it's nice to build it ourselfs.

However rtmpdump is deprecated according to your plugin and fails to download.

 

So where do you host those two projects?

 

Thanks in advance

Edited by MastaG, 6 December 2017 - 14:56.

[samsamsam]

Hello,

 

 

Also half of them don't download correctly due to difference version of openssl used in our release of OpenEmbedded.

 

 

This is not true. The version of OpenSSL it is not problem. The problem is this patch

https://github.com/o....2/soname.patch

which change SONAME. 

 

Anyway it could be fixed by creating symlinks to libssl.so.1.0.0 and libcrypto.so.1.0.0 to the binaries which name was changed to 1.0.2 by this patch.

 

Simple question what for this nam was changed? I only want to say that OpenSSL does not see the reason to change this name why openembedded feel that they know better then OpenSSL developers?

 

In case of source code of duktape and rtmpdump I will push them at free time.

In case of rtmpdump patch from K.S.V is used with additional release version info.

In case of duktape I added only some "security" patch to not allow malicious javascript code to hangs set-top-box.

 

Regards,

SSS

Edited by samsamsam, 6 December 2017 - 17:22.

[samsamsam]

@MastaG

 

I attached original sources and patch for duktape.

 

Regards,

SSS

Attached Files

•  duktape_iptvplayer-2.0.1.patch   4.61KB   33 downloads
•  org_duktape-2.0.1.tar.zip   3.47MB   35 downloads

[MastaG]

Thanks a million my friend
That will do fine.
Now all users will be able to install a compatible version of your iptv player + dependencies regardless of their platform and OE version.

Cheers

[MastaG]

Regarding rtmpdump, I can patch the release/version info myself since I know what iptv player expects.
But what is this K.S.V patch?

[athoik]

https://github.com/K...cripts/releases

[gorski]

Thanx a great big bunch to all involved!
 

From a users' point of view, am I correct in assuming this will greatly simplify things for us, in terms of installation, configuration and usage, please?

[MastaG]

@Athoik

Thank you my friend, that'll do.

 

@gorski

Well yes and no my friend

When I've added the last two recipes for duktape and rtmpdump to my feeds (+ Athoiks IPTVPlayer recipe), no more questions will be asked during the first start of the plugin.

You'll have all bits pre-installed (such as the ffmpeg binary, exteplayer3, gstplayer etc..).

So no more need to manually mess with ipks and such.

This will apply to all receivers regardless of the OE version.

 

However I can't speak for the rest of the team but I don't think the IPTV Player + dependencies will be included in the official feeds due to "various" reasons such as that it allows you to enjoy things you didn't own the rights to;)

No offense to anybody here, I personally love the plugin, so I carry it in my own feeds for my own unofficial images.

 

Anyways.. I guess the team will have to decide on this.. if they allow it I shall submit a PR to the official feed.

Then all troubles will be a thing of the past as you can just choose to install IPTV Player from the plugin browser and it'll automatically pull in all requirements.

If not.. then I guess I'll drop some unofficial builds in the near future for testing purposes or you can build it yourself

 

Btw,, thx for your nice message, I'll get back to it

Edited by MastaG, 9 December 2017 - 14:22.

[samsamsam]

@MastaG

 

Did you have chance to investigate why openembedded  change SONAME for OpenSSL libs?

[blzr]

here you go:

http://cgit.openembe...6358379b0516821

[jort38]

Now all users will be able to install a compatible version of your iptv player + dependencies regardless of their platform and OE version.

Cheers

Will this also be available for those of us (Xtrend users) on OpenPli 4.0?

[samsamsam]

@blzr

 

They are talking about different in ABI but do you have any examples what is not working?

I do not know open source component which use function which ABI have been changed.

Do you know such?

Edited by samsamsam, 9 December 2017 - 15:53.

[blzr]

here's original bug report on yocto. FWIW:

https://bugzilla.yoc...ug.cgi?id=11396

[samsamsam]

@blzr

 

To be honest it looks to me that they do not know what they doing. 

 

 

They add symbol versioning  patch to openssl. This couse that binaries build with diffrent symbol version will not work (in this case they give example with Ubuntu).

 

Meanwhile it seems like ubuntu *didn't* bump soname, nor restart on a new version symbol script. This means binaries built on ubuntu will link against the yocto 1.0.0 soname but fail due to it having the debian 1.0.2 ABI.

 

So, they change SONAME. But this will not help anyway, binaries from "Ubuntu" will still not works. 

 

They should change symbol version only for symbol which ABI has been changed. Exacly like GlibC do. 

 

If your binary use symbol with new version then it will not work with library which does not have such symbol with this version.

 

This is exactly same situation and no one get the idea to change SONAME for each GlibC version.

 

This is really funny.

Edited by samsamsam, 9 December 2017 - 16:16.

[foxbob]

I've compiled iptvplayer with your corrections. Dependencies are set and everything works. I'm asking to install a duktape which is not yet available and rtmpdump which is. But it does not affect the work. When entering the plugin, no additional components are required.

[MastaG]

True, duktape isn't a hard requirement as the one from SSS' fileserver will work just fine.

However for my images from the pyro branch, the question for installing rtmpdump will keep coming up because the stock rtmpdump from pyro doesn't contain the correct release string.

And since OE applies the SONAME patch to openssl, his binary won't work unless you create the extra symlinks.

 

It will work great nevertheless though.. it's just the wizard that keeps on asking

[MastaG]

Btw does anyone happen to have an updated KSV patch which applies to the current rtmpdump git head?

The one posted here: https://github.com/K...cripts/releases requires an older revision of rtmpdump (and I don't want to fix all rejects by hand..).

[samsamsam]

@foxbob

 

Without duktape links from  many web hosts will not work (for example from openload and manny others), you will get "No valid links", also manny www services protected for example by cloudflare protection will not work, you will get "No items to display".

 

duktape is very important utility and IPTV Player will not work correctly without it.

 

Without rtmpdump you will be not able to use buffering and recording mode for rtmp streams.

 

Regards,

SSS

[athoik]

Btw does anyone happen to have an updated KSV patch which applies to the current rtmpdump git head?
The one posted here: https://github.com/K...cripts/releases requires an older revision of rtmpdump (and I don't want to fix all rejects by hand..).

I think OE-A has the patches, check https://github.com/o...liance/rtmpdump

[foxbob]

I know rtmpdump in the system is also in the dependencies, too.I use rtmpdump_2.4.bbappend:

 

SRCREV = "fa8646daeb19dfd12c181f7d19de708d623704c0"

SRC_URI = " \

    git://git.ffmpeg.org/rtmpdump \

    file://fix-racing-build-issue.patch"

 

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"