Posts by nvdias

I've just updated the patches ... there were a lot of chenges in order to compile the tbs drivers with the new kernel version.

during the weekend I will also upload the fresh compiled drivers .

Quote from molive

Got it!

Some trouble patching dvb_frontend.c, but did it by hand. Everything looks ok now. Don't have source signal here to test the tuning, but will do so during the weekend and let you know.

Thanks for the help.

Regards,

MNO

Great !

how about sharing those patch changes ?

(it seems there are some changes to be made in other files for the last source updates ...)

The link in post #28 it is working fine:
https://mega.nz/folder/cbwCARoR#jPgzah63psSCOtrwbt9gnQ

It points to a folder with compiled drivers for Rpi4.

I've added the patches files into a zip file and uploaded it into that same folder.

le-tbs5520se-patches-220927.zip

The patches are generic for the drivers compilation.

You need to edit the module activation patch to you project (RPi2 ?) as it expects the RPi4 project.

Good luck.

And post your results here.

The patch was updated for One of the latest kernel versions.

Please try one of the last links some posts above.

If not, I will re-upload the patch later.

Quote from molive

Hi,

Trying to replicate for RPi2. Its building ok, but TBS5520 is not installing. Shows on lsusb, but not on lsmod.

Any help appreciated.

Thanks in advance.

MNO

Have you adjusted the tbs5520se patches to be applied into rpi2 project / device ?

Quote from Microka

LibreELEC-Generic.x86_64-10.0.2 (Linux Kernel 5.10.76), could you help to compile drivers for this? Thank you!

Hi. Sorry. But at the moment I can only maintain compilations for RPi4.

If you want to yourself for x86_64, just create the compilation environment and toolchain. following official instructions:

https://wiki.libreelec.tv/development-1/build-basics

Once you are able to create a LE image, came back here. I will help inject the patches for x86_64.

I've made some new tests with debian buster image in a docker container running within libreelec RPI.

followed instructions from libreelec github:

LibreELEC.tv/tools/docker at master · LibreELEC/LibreELEC.tv

Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.

github.com

but the same:

Error: unknown architecture `armv8-a+crypto'

It seems that libelec project forces:

FLOAT: hard

But docker container is running with software float.

Is it possible to force the compilation with FLOAT: soft ?

or any trick in "docker run" to allow FLOAT_hard within running containers ?

thanks

I'm now with LE11 form quite some time.

not using LE10 anymore.

I have the drivers compiled for LE11 kernel 5.15.45. It should be compatible with LE10 if you are in the same kernel version:

(confirm with "uname -a")

Available in the same folder:

https://mega.nz/folder/cbwCARoR#jPgzah63psSCOtrwbt9gnQ

Quote from CvH

https://wiki.libreelec.tv/development-1/building-windows-wsl

works and is similar fast compared to native building

That's great !

Thanks' I will definitively try it.

Anyway it would be great to use the RPi I have with LE.

Afterall I have it turned on 24/7 and available most of the time.

I usually compile overnight (But I need to insert the SD with UBUNTU).

The ability to compile inside a docker container running inside LE itself would be fantastic.

Is there a way of solving the error I get in the container ?

crypto/aes/aesv8-armx.S:4: Error: unknown architecture `armv8-a+crypto'

Thank you very much

I've been making my LibreELEC 11 for RPI4 testing compilations using a Ubuntu VM in Windows.

Have also successfully compiled in Ubuntu for Raspberry Pi - takes hours .... but it compiles 😁

New test:

Inside LibreELEC.

Pulled an Ubuntu docker image into LibreELEC

prepared the compilation environment, created a specific user in the docker container (libreelec does not compile as root)

As usual, started compilation with:

PROJECT=RPi DEVICE=RPi4 ARCH=arm make image

But is stops with error:

crypto/aes/aesv8-armx.S:4: Error: unknown architecture `armv8-a+crypto'

Any suggestions to turn-around this ?

Thanks

likewise

yeah. me too !

that's why I'm asking

I've tried also "git ignore" for that commit, but it also fails.

Quote from chewitt

Nightlies are experimental development images so users should expect bugs and delays in fixing things. Our normal preference is to report the fix and then bump to include the resolution patch or another bump rather than revert back. If it becomes clear the issue won't be resolved quickly, then we'll revert the version.

What is the best apoach to compile the current nightly but ignoring the last samba update ?

Will patching packages/network/samba/package.mk (for the old 4.15.6 ) be enough ?

followed by:

PROJECT=RPi DEVICE=RPi4 ARCH=arm scripts/clean samba

PROJECT=RPi DEVICE=RPi4 ARCH=arm scripts/clean heimdal

PROJECT=RPi DEVICE=RPi4 ARCH=arm make image

?

thanks

as the bug is identified and already known, shouldn't the samba version be reverted back to a working one ?

(in the libreelec nightlies), of course.

Quote from heitbaum

Known issue - https://github.com/LibreELEC/Libr…ment-1079720666

issue raised on samba email list -

• https://lists.samba.org/archive/samba/2022-March/240221.html

ok. thanks

From the last nightly versions I've noticed it is not possible to browse the list of shares.

If i try direct access to a share like \\ipaddress_libreelec\storage from a windows 11 machine --> it works ok.

If i just try to list the shares \\ipaddress\ it says "windows cannot access ipaddress" !

Note:

I've removed the file /storage/.config/samba.conf and reboot, in order to force a default config, but it has the same behaviour.

In LibreELEC kodi interface sambe is configured with SMB1 as min protocol, and SMB3 as max.

thanks

I've just compiled and installed the current master branch from github.

I've been watching TV for the entire afternoon without any visible artefacts or any reported error in tvheadend.log

I'm not proficient enough to understand if there were changes in the code that may have produced this new behaviour (apart some changes in ffmpeg that were merged yesterday in the branch) or if it is just some weird coincidence.

I will keep in tests during the weekend and will mark the thread as solved next monday if that is the case.

thanks

Made new tests with 2 Raspberry Pi 4.

Both in the same lan network:

RPi4 #1 -> LibreELEC 9.2.8, dvb-C dvb-S receiver + tvheadend server + tvheadend player addon

OK

RPi4 #2 -> LibreELEC 11 nightly build, tvheadend player addon, connected to RPi4 #1 (tvheadend server)

All goes OK !

Notes:

• Using LE10 or LE11 in the server also works ok in this "distributed architecture".
• tvheadend server is the same binary across every test. (4.3 nigthly build 2009).

Result:

The green screens artefacts are only appearing if using both tvheadend server + player in the same Rpi4 when running LE10/LE11.

Hope this helps somehow in solving the problem.