168 replies to this topic

[WTE]

I'm not adding Kodi to the image. I'm installing it from my feed after I run MACHINE=h7 bitbake openpli-enigma2-feed. Once I do that, image is not booting anymore. Very odd. Installing other packages like serviceapp and exteplayer from my feed is OK. 

Ok then I understand you wrong. So it must been check which packages are extra installed and if one or more packages cause the boot failer. So this "new" packages should been start by boot. So think easist way is to control if /etc/init.d is something added or changed and /etc/RC.x was is added. (Can check date and time of file)

I will check tomorrow a bit if I can see something strange.

Edited by WTE, 21 June 2020 - 18:54.

[peti]

it even does not start to boot, no boot image, no signal on the spdif output. 

[daimon]

Yes the problem exists on zgemma h7, with kodi in the first zeus builds

once you get around the rootfs problem the box

he left regularly,

 

in the latest builds there is something that prevents the box from starting

 

the box returns to function only by removing kodi

[peti]

just tried the latest head of dev branch, and my h7 is still not booting after Kodi is installed. any idea how to fix this issue?

Edited by peti, 23 July 2020 - 07:53.

[A.A.]

@WTE

 

At least on vuduo2 you can have kodi built-in or install it later and no issues arise. No multiboot here.

 

About kodi, I think I'll open a new thread...

I am looking at the diffs with OE-A and there are some big ones with the patchset we have in OpenPli.

 

- different STB patchset

- strange FFMPEG handling (version check + patches)

- kodi startup script (moving HOME)

- different targets (v3d/vuplus) added by the recipe as 'platforms'

- pulseaudio in packageconfig

- replacement of external fmt with libfmt

 

Plus other small differences

 

My question is now, do this recipe run on other boxes?

On vuduo2 I get the Bus Error / SIGBUS but what bus?

 

Cheers

A.A.

Edited by A.A., 27 July 2020 - 14:30.

[foxbob]

I collected for duo2 and solo2 according to these recipes.It collects without errors,but the kodi does not start.There are no problems with 4K receivers,everything works.

Edited by foxbob, 27 July 2020 - 15:02.

[foxbob]

Again I put together for solo2 and duo2 codi18.8 and again codi does not start.There are no more thoughts.

[A.A.]

@foxbob

 

now that the temperatures are human I am again at it.

I fear there is some problematic piece in zeus  ()toolchain, python, dbus, ?) so I have built 7.3 and backported  kodi 18.8.

We can rule out the new GL headers, same error with older ones.

 

Unfortunately yesterday I got fetch errors...I fear github screwed again the commit hashes, will look at this today.

 

Cheers

A.A.

[A.A.]

about kodi fetch failure...my bad (perhaps): the phantom SRCREV was in reporefs.conf.

 

I am used to a pure oe-core setup as it was 10yrs ago....

 

I see there jsonschemabuilder-native as well and I am wondering about fetching specific subdirs for it and for texturepacker-native.

They share the same xbmc SRC_URI but with different revs.

 

Fixes for later, for now I'll try kodi on 7.3

 

A.A.

[A.A.]

Testing kodi 18.8 on release 7.3 was not productive, same "Bus Error"

 

With gdb I see it is also failing in the same place,  gitt/xbmc/platform/posix/main.cpp

 

  // Set up global SIGINT/SIGTERM handler
  struct sigaction signalHandler;
>  std::memset(&signalHandler, 0, sizeof(signalHandler));
  signalHandler.sa_handler = &XBMC_POSIX_HandleSignal;
  signalHandler.sa_flags = SA_RESTART;
  sigaction(SIGINT, &signalHandler, nullptr);
  sigaction(SIGTERM, &signalHandler, nullptr);

 

Unfortunately there is a bug in this sumo-OE so the debugfs does not contain the sources...

 

I think it is that memset but need much more time to follow the code flow line by line, too many shlibs are loaded!

I'll go back to develop/zeus for debugging.

 

Cheers

A.A.

[littlesat]

It should be tried on 8.0 now in development.... (Zeus)

Edited by littlesat, 20 August 2020 - 14:21.

[foxbob]

I collect on this thread.For any 4K receivers,there are no problems - kodi18,kodi19 going and running.But somehow for solo2 and duo2 there is a startup problem.Version kodi17.6 built and worked without problems.

[A.A.]

@littlesat

I have started with develop branch (zeus) but ifor vuduo2/mipsel t terminates with SIGBUS

So just for fun I wanted to see if the culprit was the toolchain or the different revisions of headers, python, etc.

Same result, SIGBUS

 

@foxbob

the recipe as it is in develop has a couple of flaws, first one is kernel defconfig, then the missing libxbmc_base.so in /usr/lib

 

In my github forks I am putting together the patches for zeus branch.

I was hoping to solve it earlier but there is still some little piece missing, must check again the OE-A differences.

 

I am now tempted to send pull request to have at least the current fixes merged.

Once solved this issue I'd like to refactor the recipe and split the BSP stuff in the respective layers.

 

Cheers

A.A.

[A.A.]

P.S.

@WTE, WanWizard

Pending commit is about introducing 'dvbproxy' in MACHINE_FEATURES.

I have tested these drivers for one month and they are rather stable.

 

Two questions in my mind:

1 - why did VU+ ship two set of drivers (vuplus-dvb-modules and vuplus-dvb-proxy)

2 - why didn't OpenPLi move to the new drivers like almost all other distros?

 

Regards

A.A.

[foxbob]

Here is a screenshot of the installation files.

Try my build.

https://drive.google...iew?usp=sharing

 

Attached Files

•  Снимок экрана от 2020-08-20 23-27-35.png   56.45KB   4 downloads

[WanWizard]

2 - why didn't OpenPLi move to the new drivers like almost all other distros

 

We use the BSP as provided by VU+. If that doesn't contain the newest drivers, there are two possible options:

 

1. The drivers are beta drivers. A lot of vendors release those to OE-A so they can do the testing for them, and only after testing is the BSP updated

2. VU+ forgot to update the BSP, in which case they need some kickin'...

[A.A.]

Using valgrind I got this

 

https://pastebin.com/D4GxFdH6

 

But in do_configure

 Found EGL: /tmp/build/tmp/work/vuduo2-oe-linux/kodi/1_18.8+gitrAUTOINC+0e37911544-r0/recipe-sysroot/usr/lib/libEGL.so

and in fact it is there...

 

Note that I started kodi-stb  without args

 

Investigating..

 

A.A.

[Erik Slagter]

Shouldn't this thread be better called something like "Kodi on Zeus and newer"?

[A.A.]

Yeah, but this could be good news...no other software has such issues on mipsel in develop branch (SIGBUS).

 

I am now ending up with the conclusion that the binary is probably miscompiled/badly linked and one OE-A commit hints at this [1]

 

But it is not only this: some kodi dependencies in /recipes-support (fmt, libnfs, flatbuffers) are different/are patched  in OE-A which is known as 'working example'.

So I am following this and also adapting 'our' recipe adding the packageconfig bits and the block of DISABLE_INTERNAL options (and more). I just need to add pulseadio now.

 

Recently I found an interesting fork of meta-kodi with a supposed 'fix' for kodi [2] which makes me doubt of fmt. Note that in this fork the 'multilib/fixes' of 'captain' are ignored by the upgrades...

Ah, upgrading to fmt > 4.0 makes the kodi builddir over 13GB...doh! Something was ignored? Something is double?

 

This period is for me very busy but I plan to continue testings on weekend, hoping that someone jumps in to help.

 

Cheers

A.A.

 

[1] https://github.com/o...3af707386e3cad2

[2] https://github.com/d...ae4483ac39678a1

[Erik Slagter]

Indeed, a sigbus very much suggests wrong compilation options (sub-arch).