Jump to content


Adblock Plus
Advertising seems to be blocked by your browser.

Please notice that advertising helps us to cover the cost of hosting the project.

If you find these ads displayed intrusive or inappropriate, please contact the webmaster.
Photo

devel: kodi_18 vs mipsel


  • This topic is locked This topic is locked
126 replies to this topic

Re: devel: kodi_18 vs mipsel #21 WanWizard

  • PLi® Core member
  • 71,142 posts

+1,840
Excellent

Posted 25 April 2021 - 15:10

:thumbs-up:


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: devel: kodi_18 vs mipsel #22 Aliraza63

  • PLi® Tester
  • 251 posts

+23
Neutral

Posted 27 April 2021 - 08:54

read somewhere in other forums  in Openspa kodi 18.9  is working fine in mips  (duo2 ) no audio issue at all .

is it true ? 


 DM-900 ,DM-520, Vu+Duo2


Re: devel: kodi_18 vs mipsel #23 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 27 April 2021 - 10:02

#WanWizard

 

I tried to split kodi_18.inc and create the .bbappend in meta-vuplus but it is impossible...purposedly blocked.

 

https://github.com/v...4b4896eb103c243

 

We have two options imho:

 

1- insist with vuplus and revert that commit.  Need to add layer dependencies as well to the openpli layer in this case.

2 -create a bogus kodi-vuplus_18.bb which includes the main .bb. Ofc layer deps should be added.

 

Any idea?

Cheers

A.A.



Re: devel: kodi_18 vs mipsel #24 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 27 April 2021 - 10:07

read somewhere in other forums  in Openspa kodi 18.9  is working fine in mips  (duo2 ) no audio issue at all .

is it true ? 

Yes, on vuduo2 the OE-A images provide a running kodi for stb. I did not test sound on it yet.

We are now trying to spot the difference making kodi  crash on OpenPli: we are basically sure it builds correctly.

 

I personally don't know kodi internals, I think it tries to open some connection and fails (SIGBUS).

But which one? Linux input? Sound bus? dvb video sink?Networking? ....

 

WIP

 

A.A.



Re: devel: kodi_18 vs mipsel #25 ntj

  • Senior Member
  • 76 posts

0
Neutral

Posted 27 April 2021 - 10:19

read somewhere in other forums  in Openspa kodi 18.9  is working fine in mips  (duo2 ) no audio issue at all .

is it true ? 

Yes, to answer your question.

 

I have tried Openspa with Kodi 18.9 on both DUO2 (mips) and Ultimo4k. (arm)

Both are working good and with sound.



Re: devel: kodi_18 vs mipsel #26 Aliraza63

  • PLi® Tester
  • 251 posts

+23
Neutral

Posted 27 April 2021 - 11:23

 

read somewhere in other forums  in Openspa kodi 18.9  is working fine in mips  (duo2 ) no audio issue at all .

is it true ? 

Yes, to answer your question.

 

I have tried Openspa with Kodi 18.9 on both DUO2 (mips) and Ultimo4k. (arm)

Both are working good and with sound.

 

 

Thanks for the reply . I have tested now to . yes its working fine in my duo2 and duo4k to


 DM-900 ,DM-520, Vu+Duo2


Re: devel: kodi_18 vs mipsel #27 WanWizard

  • PLi® Core member
  • 71,142 posts

+1,840
Excellent

Posted 27 April 2021 - 11:32

https://github.com/v...4b4896eb103c243

 

We have two options imho:

 

1- insist with vuplus and revert that commit.  Need to add layer dependencies as well to the openpli layer in this case.

2 -create a bogus kodi-vuplus_18.bb which includes the main .bb. Ofc layer deps should be added.

 

What exactly is the issue with this?

 

It only removes bbappend capability from the BSP, which is indeed a good thing, we don't want a BSP appending to recipies outside the BSP.

 

So if kodi for VU+ requires something special, it needs to be addressed in the kodi recipes (there are already exceptions for VU+ present).


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: devel: kodi_18 vs mipsel #28 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 27 April 2021 - 12:33

 

https://github.com/v...4b4896eb103c243

 

We have two options imho:

 

1- insist with vuplus and revert that commit.  Need to add layer dependencies as well to the openpli layer in this case.

2 -create a bogus kodi-vuplus_18.bb which includes the main .bb. Ofc layer deps should be added.

 

What exactly is the issue with this?

 

It only removes bbappend capability from the BSP, which is indeed a good thing, we don't want a BSP appending to recipies outside the BSP.

 

So if kodi for VU+ requires something special, it needs to be addressed in the kodi recipes (there are already exceptions for VU+ present).

 

 

 

Nothing really forbids to have .bbappends in the BSP layers...in fact it is the standard in OE/Yocto for the kernels... [1]

 

Anyway the thing is that in an ideal world meta-openpli should not contain machine-specific recipes nor variables with machine-overrides (ie blah_vuduo2).

Ideally it should not even contain a kodi.bb but just a .bbappend pointing to the meta-kodi layer...

 

So that kodi_18.inc should not exist there :)

 

my 2 cents

A.A.

 

 

[1] https://www.yoctopro...html#bsp-layers



Re: devel: kodi_18 vs mipsel #29 WanWizard

  • PLi® Core member
  • 71,142 posts

+1,840
Excellent

Posted 27 April 2021 - 12:36

I know it is not forbidden, the problem is that they may alter recipes from elsewhere. For the rest, I completely agree with you that all hardware linked recipes should be in the BSP.

 

It is different when, like OE-A, one controls everything, and one can setup the correct structure from scratch. With BSP's not being under our control, it is always going to be difficult.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: devel: kodi_18 vs mipsel #30 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 27 April 2021 - 14:23

One more question: the recipe was imported from meta-kodi and we unconditionally inherit systemd.

 

What are the effects? None?

I'd say it should be first checked against DISTRO_FEATURES.

 

A.A.



Re: devel: kodi_18 vs mipsel #31 WanWizard

  • PLi® Core member
  • 71,142 posts

+1,840
Excellent

Posted 27 April 2021 - 14:42

Where is that? I don't think that has any effect if systemd isn't used, a lot of recipe's have systemd support.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: devel: kodi_18 vs mipsel #32 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 27 April 2021 - 14:50

It should not harm.

 

It's here

https://github.com/O.../kodi_18.bb#L14

 

Instead, more relevant is perhaps pulseaudio?

https://github.com/o...kodi_18.bb#L142

 

I don't see special reasons for it but maybe there are...

 

Cheers

A.A.



Re: devel: kodi_18 vs mipsel #33 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 28 April 2021 - 10:40

While the OE-A image is unbuildable atm (samba) I installed OpenSPA and immediately installed kodi on it.

Here the logs: https://pastebin.com/PxY4yPbq

 

BTW we have different directfb versions

 

WIP

A.A.



Re: devel: kodi_18 vs mipsel #34 WanWizard

  • PLi® Core member
  • 71,142 posts

+1,840
Excellent

Posted 28 April 2021 - 12:32

Your last change produced an error in the nightly builds for all Zgemma ARM models (H7 and up):

2021-04-28 11:05:14 ERROR: kodi-1_18.9+gitrAUTOINC+0655c2c718-r0 do_package_qa: QA Issue: /usr/lib/kodi/kodi-stb contained in package kodi requires libEGL.so, but no providers found in RDEPENDS_kodi? [file-rdeps]
2021-04-28 11:05:14 ERROR: kodi-1_18.9+gitrAUTOINC+0655c2c718-r0 do_package_qa: QA Issue: /usr/lib/kodi/kodi-stb contained in package kodi requires libGLESv2.so, but no providers found in RDEPENDS_kodi? [file-rdeps]
2021-04-28 11:05:14 ERROR: kodi-1_18.9+gitrAUTOINC+0655c2c718-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
2021-04-28 11:05:14 ERROR: Logfile of failure stored in: /openpli/oe/develop/build/tmp/work/h10-oe-linux-gnueabi/kodi/1_18.9+gitrAUTOINC+0655c2c718-r0/temp/log.do_package_qa.27315
2021-04-28 11:05:14 ERROR: Task (/openpli/oe/develop/meta-openpli/recipes-mediacenter/kodi/kodi_18.bb:do_package_qa) failed with exit code '1'

 


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: devel: kodi_18 vs mipsel #35 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 28 April 2021 - 12:51

Ah, ok,

 probably they have PRIVATE_LIBS ot there isn't the rprovider.

 

Vuplus seems fixed but if you want we can readd the INSANE_SKIP but limiting it to the affected machines.

Something like INSANE_SKIP_${PN}_Zgemma-model

 

A.A.

 

Edit: it does provide the rdepended libs. No private libs.

https://github.com/z...ddriver.inc#L11

 

zgemma-v3ddriver-h7 should be added to _zgemma-model rdeps of kodi then.


Edited by A.A., 28 April 2021 - 13:00.


Re: devel: kodi_18 vs mipsel #36 WanWizard

  • PLi® Core member
  • 71,142 posts

+1,840
Excellent

Posted 28 April 2021 - 13:00

The machines failing are: h7, h9, h10, h11, h9se, h9combo, h9combose, i55se, i55plus


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: devel: kodi_18 vs mipsel #37 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 28 April 2021 - 13:23

h7 -> "zgemma-v3ddriver-${MACHINE}"

h9, h9se, h9combo, h9combose, h10, i55se, i55seplus  -> "zgemma-mali-3798mv200"

h11 -> "zgemma-mali-3798mv310"

 

AFAIS we should add that BSP-derived stuff to kodi_18.inc

 

Cheers

A.A.

 

P.S.

Sorry for the mess, I am building for vuduo2 only atm


Edited by A.A., 28 April 2021 - 13:26.


Re: devel: kodi_18 vs mipsel #38 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 28 April 2021 - 13:29

I am now wondering..is it better to add virtual/egl to RDEPENDS to catch all these cases?

A.A.



Re: devel: kodi_18 vs mipsel #39 WanWizard

  • PLi® Core member
  • 71,142 posts

+1,840
Excellent

Posted 28 April 2021 - 14:41

I don't know, I'm far from a bitbake expect... :)

 

If you want me to test something, let me know, I have a local build environment for the h9.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: devel: kodi_18 vs mipsel #40 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 28 April 2021 - 15:21

Kodi has virtual/egl in depends and that should be enough for the buildsystem to register [1]

 

The problem seems to be with the recipe dlopen'ing at runtime or with the unversioned shlibs or when libs are declared private_libs: the conclusion is we need libEGL.so and libGLESv2.so

 

 

I think we could add more lines to kodi_18.inc for these Zgemma like:

 

#Zgemma

RDEPENDS_${PN}_append_h7 = " zgemma-v3ddriver-h7"

RDEPENDS_${PN}_append_h9 = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_h9se = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_h9combo = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_h9combose = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_h10 = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_h11 = " zgemma-mali-3798mv310"

RDEPENDS_${PN}_append_i55se = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_i55seplus = " zgemma-mali-3798mv200"

 

 

Or maybe adding a generic RDEPENDS_${PN}_append = " virtual/egl virtual/libgles2"

This would be one-liner but need some more thoughts...

 

A.A.

 

 

[1] https://www.yoctopro...me-dependencies


Edited by A.A., 28 April 2021 - 15:23.



0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users