Posts by heitbaum

Hi adam.h.

Closed pull requests good to look at too.

- https://github.com/LibreELEC/LibreELEC.tv/pulls

In answer to your question.

Kodi - https://github.com/LibreELEC/LibreELEC.tv/pull/6291

Kernel - (in tomorrows nightly) https://github.com/LibreELEC/LibreELEC.tv/pull/6210

Intel stuff - https://github.com/LibreELEC/LibreELEC.tv/pull/6302

Mesa - https://github.com/LibreELEC/LibreELEC.tv/pull/6288

Nightlies does not have the wip HDR patches - if that is a consideration.

Otherwise nightlies are kept current with Intel+Mesa, with Kodi and Kernel regularly (no real rule around this - usually a draft kernel PR in place for the kernel)

You can check the history of both of these

- https://github.com/LibreELEC/Libr…inux/package.mk

- https://github.com/LibreELEC/Libr…kodi/package.mk

You will be able to use modprobe once the .ko file is included in the modules directory - after the https://github.com/LibreELEC/LibreELEC.tv/pull/6312 request is added to the build. I believe that you will still need the “echo” during boot to enable the readings, via either systemd or autostart.sh

For the moment. Just use “insmod jc42.ko” (/storage is fine)

Compiled up:

build.LibreELEC-Generic.x86_64-10.0-devel/build/linux-5.10.76/drivers/hwmon/jc42.ko

Grab it from here.

LibreELEC.tv/jc42.ko at dev · heitbaum/LibreELEC.tv

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

github.com

If all works right… share the output and howto, and I’ll raise a PR for the module addition.

What version of LE10 are you running? Please confirm (ideally 10.0.2) and I will try an get a test jc42 for you.

nuc11:~ # uname -a

Linux nuc11 5.17.0-rc8 #1 SMP Fri Mar 18 09:21:50 UTC 2022 x86_64 GNU/Linux

nuc11:~ # cat /etc/release

Generic.x86_64-devel-20220318085355-518a13c

nuc11:~ # head .kodi/temp/kodi.log

Hi SandVP

A quick check here and jc42 is not adding to sensors on NUC11PAHi7

nuc11:~ # i2cdetect -l

i2c-0 i2c i915 gmbus dpa I2C adapter

i2c-1 i2c i915 gmbus dpb I2C adapter

i2c-2 i2c i915 gmbus dpc I2C adapter

i2c-3 i2c i915 gmbus tc1 I2C adapter

i2c-4 i2c i915 gmbus tc2 I2C adapter

i2c-5 i2c i915 gmbus tc3 I2C adapter

i2c-6 i2c i915 gmbus tc4 I2C adapter

i2c-7 i2c i915 gmbus tc5 I2C adapter

i2c-8 i2c i915 gmbus tc6 I2C adapter

i2c-9 i2c AUX USBC1/DDI TC1/PHY TC1 I2C adapter

i2c-10 i2c AUX USBC2/DDI TC2/PHY TC2 I2C adapter

i2c-11 i2c AUX USBC3/DDI TC3/PHY TC3 I2C adapter

i2c-12 i2c AUX USBC4/DDI TC4/PHY TC4 I2C adapter

i2c-13 i2c Synopsys DesignWare I2C adapter I2C adapter

i2c-14 smbus SMBus I801 adapter at efa0 SMBus adapter

nuc11:~ # i2cdetect -y 14

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: 08 -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: 30 -- -- -- -- 35 UU UU -- -- -- -- -- -- -- --

40: -- -- -- -- 44 -- -- -- -- -- 4a 4b -- -- -- --

50: UU -- 52 -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

nuc11:~ # insmod http://LibreELEC.tv/build.LibreELEC-Generic.x86_64-11.0-devel/build/linux-5.17-rc8/drivers/hwmon/jc42.ko

nuc11:~ # sensors

coretemp-isa-0000

Adapter: ISA adapter

Package id 0: +36.0°C (high = +100.0°C, crit = +100.0°C)

Core 0: +30.0°C (high = +100.0°C, crit = +100.0°C)

Core 1: +32.0°C (high = +100.0°C, crit = +100.0°C)

Core 2: +32.0°C (high = +100.0°C, crit = +100.0°C)

Core 3: +33.0°C (high = +100.0°C, crit = +100.0°C)

acpitz-acpi-0

Adapter: ACPI interface

temp1: -263.2°C

temp2: +37.0°C (crit = +119.0°C)

iwlwifi_1-virtual-0

Adapter: Virtual device

temp1: N/A

nvme-pci-0100

Adapter: PCI adapter

Composite: +32.9°C (low = -0.1°C, high = +69.8°C)

(crit = +84.8°C)

Correct. 5.12 at a minimum and really 5.15 for good function. There are also a lot of Intel patches in nighties over the last 12 months.

Hi Mettbrot I haven’t had an out of sync screen for a while now. I have connected the nuc11 via the AVR too. I am running my dev branch image - but nightly Generic is pretty similar for the purposes of the Intel packages.

Hi debarr Matrix was moved to Python3 - more info here - https://kodi.wiki/view/General_i…ion_to_Python_3

Hi succo - the nightlies use GBM (not x11) - you will need to use a (wl or x11) image - which has some nvidia support - this is not compiled as a nightly - so you will need to compile your own.

Looking at the R&D we have now undertaken - I think the sentence could be written something like:

using samba to serve files from kernel ntfs3 …… whereas using samba to serve files from ext4 ….. In earlier kernel versions …. using ntfs-3g, samba was able to serve files from the ntfs external drive … (without issue) …..

I’m not sure that we have validated anything else yet? What does

time dd if=file.mov of=/dev/null bs=4m 

(or similar) show from a performance perspective? From each of the file system types?

Hi beredim - looks like it was added in 5.13-rc1 - https://lkml.org/lkml/2021/4/27/526

Any reason why you would want to run the PN50 with LE10 versus the nightlies? I know I had to run 5.12+ to get a good experience with the Intel TGL. Naming patch files is done via git-format-patch. And the numbering is not really formalised in the Linux patches - whilst the Kodi patches are “999.* - patches backported from upstream”? I’m probably not in favour of backporting that patch into the libreelec-10.0 branch as a patch. Was the patch backported in into the 5.10.x series? (Could be an option to bump the kernel to 5.10.x) From a testing perspective - any patch in default should,be tested against all of the other architectures.)

An alternative option for you could be to backport the couple of 5.15 commits from HEAD into your development branch and run with your community image. The planned release schedule of 10.0.x is definitely not fast and furious

At some stage there will be a kernel bump for Generic (but probably not till 10.2 and would probably be a backport of something from nightlies). But none planned for 10.0.x at this time.

mo123 as someone in the last 18 months who has learnt the ropes on what is required to maintain the packages for a distribution (and the occasional other bits and pieces) a challenging - but rewarding investment of time. As you you will have seen in my Kernel / u-boot PRs started out getting a build system together and the list of tests… then a lot of test / update. Even a patch into 5.17-rc6 to fix the Qualcomm build issue.. For packages spending time testing pre-releases, discussing, fixes to and testing upstream, so that we can use the released versions. For the RK - happy to test against RK3308, RK3399pro, RK3568, RK3388 - though only have the 3308 on my desk at the moment… might be an excuse to get the others back on my desk.

Quote from camelreef

Can you believe that I have not yet been offered a Samba bugzilla account or got any feedback from them after 3 attempts?

Also, the Samba 4.16 inclusion in LE11 must have taken a back seat in favour of more pressing matters.

on my work list … not forgotten but kernel 5.16.11 and gcc / glib and binutils trumped it. ETA on 4.16 in nightlies would be mid/late march at this stage. Waiting till 4.13 goes EOL and I push the final 4.13 into LE11/LE10 - then can drop 4.16 in. There is still compile error (probably I need to update the patch - but only did the basics on the PR to get it unpacking and compiling as my WIP)

offbeat - message from the PR - so looking like the addons, etc.

==

crashes are skin related (estuary mod v2), I contacted author.

_Originally posted by @polojoe in https://github.com/LibreELEC/Libr…ent-1045970954_

Included in media-driver 22.2.1 now - https://github.com/LibreELEC/LibreELEC.tv/pull/6242

On versioning - Samba 4.13 is being tracked as it is in LE10(and one of the few packages that is backport Ed - for its security fixes). In March/April - security patches will stop being released for 4.13 and the :master will start tracking the to be released 4.16 release of Samba.

As a note - the Ntfs version being used in nightlies is now ntfs3 - https://github.com/LibreELEC/LibreELEC.tv/pull/5838 - which is the Paragon Kernel version. but it is a different version to the ntfs3g that we and other distributions were using before kernel 5.15.