Posts by HiassofT

The updated kernel is now in nightly builds. Please test with the latest build (currently 2024-08-02) from here https://test.libreelec.tv/12.0/RPi/RPi5/

so long,

Hias

Please test with those builds, hopefully they'lll help to narrow it down a bit:

RPi4: https://www.horus.com/~hias/tmp/libr…455-ddbb512.tar
RPi5: https://www.horus.com/~hias/tmp/libr…425-ddbb512.tar

They are current LE12 builds and have kodi compiled with debug info plus the leak sanitizer enabled (for the self builders: include the top 2 commits from this branch https://github.com/HiassofT/Libre…le12-sanitizers and build with DEBUG=kodi)

After stopping kodi (systemctl stop kodi) the sanitizer will output detailled info about leaked memory. For now look at the summary (run systemctl status kodi | grep SUMMARY after stopping kodi).

First stop kodi pretty immediately after startup to get a baseline. Here on RPi5 I see about 900k leaked in a bit over 2k allocations:

Aug 03 12:25:43 LibreELEC kodi.sh[1097]: SUMMARY: LeakSanitizer: 936782 byte(s) leaked in 2027 allocation(s).

Then reboot, let kodi run for some time until you see increased kodi memory usage / less free memory, stop kodi and check the summary again.

Please report the values you got for baseline and in the "increased memory" case.

Here in local tests (just letting kodi idle on the main screen) I couldn't see much difference between 30s, 6min and 15min running time.

After 6min I got

Aug 03 12:22:33 LibreELEC kodi.sh[980]: SUMMARY: LeakSanitizer: 920304 byte(s) leaked in 2030 allocation(s).

And after 15min I got

Aug 03 13:03:04 LibreELEC kodi.sh[1198]: SUMMARY: LeakSanitizer: 920296 byte(s) leaked in 2029 allocation(s).

Hopefully your tests will show significantly more leaked memory, then we can start looking further into the actual allocations.

so long,

Hias

On Generic legacy kodi (actually X11) doesn't grab the input devices so logind will "see" power/suspend/hibernate button presses and handle them.

The login power button handling is set to "ignore" in Generic Legacy but if your remote sends KEY_SLEEP (=suspend to ram) or KEY_SUSPEND (=hibernate) logind will put your system to sleep.

You can change that behavior by creating a /storage/.config/logind.conf.d/disable-suspend.conf file with the following contents and reboot:

[Login]
HandleSuspendKey=ignore
HandleHibernateKey=ignore

Now logind will ignore those buttons and you can configure the desired behaviour in kodi.

so long,

Hias

Quick heads up: the kernel update needs to wait a bit longer, the TV-HAT fix introduced a regression: https://github.com/raspberrypi/linux/issues/6285

so long,

Hias

I'm planning to update the RPi kernels in the next few days, if testing goes well the fix should be in the LE12 and LE13 nightly images soon.

so long,

Hias

evtest will show you the scan code, you need to stop kodi first though.

See also here RE: Ok button doesn't work on H1 remote

so long,

Hias

Kodi will grab the input devices so other programs (evtest, your python script, etc) won't see any input on them.

Instead of jumping through hoops with a separate python script it's better to just create a hwdb file with the adjusted button/key mappings, see eg here: RE: Ok button doesn't work on H1 remote

so long,

Hias

Please test with the latest nightly build from here https://test.libreelec.tv/12.0/ (for RPi5 it's currently https://test.libreelec.tv/12.0/RPi/RPi5/…-a2b8ac8.img.gz).

The nightly builds include a fix for the partition/filesystem resizing issues after initial installation on large drives - see https://github.com/LibreELEC/LibreELEC.tv/pull/8817

so long,

Hias

That's a known issue and already fixed in current nightly builds. See here:

Post

RE: LE 11.95 : display problem on rpi4 + official 7-inch screen

The fix is now in the latest LE12 nightly build (20240505)
RPi4: https://test.libreelec.tv/12.0/RPi/RPi4/…-5087609.img.gz
RPi5: https://test.libreelec.tv/12.0/RPi/RPi5/…-5087609.img.gz

Can you please give it a try?

so long,

Hias

HiassofT

May 6, 2024 at 9:32 AM

so long,

Hias

vc4.force_hotplug is incompatible with 4kp60 which you are using as GUI resolution so this is expected.

I recommend setting the GUI resolution to 1920x1080 and setting up the whitelist as described in the wiki https://wiki.libreelec.tv/configuration/4k-hdr

Also please drop vc4.force_hotplug from cmdline.txt and make sure you use a proper cable/connection which signals hotplug properly as otherwise you'll have the same issue whenever switching inputs or TV on/off while the RPi switched to 4kp60 during video playback.

so long,

Hias

This indicates you are using an improper HDMI cable or a case with an improper internal HDMI adapter.

4kp60 was deliberately enabled for RPi4 in LE12 to bring it in line with RPi5 (which has 4kp60 enabled by default).

so long,

Hias

I'm not familiar with MACs or "extfs for mac" but I'd guess you need an updated version of extfs for mac that can cope with the new ext4 options used by current ext4fs tools (mkfs.ext4 etc).

Older linux systems have similar issues and some linux distributions disabled the new options to make filesystems compatible with older linux versions, but we don't do that in LE.

so long,

Hias

The updated firmware is now in the latest nightly build (20240505):
https://test.libreelec.tv/12.0/RPi/RPi4/LibreELEC-RPi4.aarch64-12.0-nightly-20240505-5087609.img.gz

Can you please give it a try?

so long,

Hias

The fix is now in the latest LE12 nightly build (20240505)
RPi4: https://test.libreelec.tv/12.0/RPi/RPi4/…-5087609.img.gz
RPi5: https://test.libreelec.tv/12.0/RPi/RPi5/…-5087609.img.gz

Can you please give it a try?

so long,

Hias

A fix for that was committed to the RPi kernel 2 days ago https://github.com/raspberrypi/linux/pull/6094

I'll add it to LE nightlies soon.

so long,

Hias

You can also simply disable network install, run rpi-eeprom-config -e and add NET_INSTALL_ENABLED=0

see also here: https://www.raspberrypi.com/documentation/…INSTALL_ENABLED

so long,

Hias

When you open a HDMI audio device on the RPi the kernel automatically chooses a channel map based on the number of channels (eg 8 in this case) and the speaker allocation from the EDID.

The hdmi-codec driver has an ordered list, sorted by preference, and will choose the first entry that's supported by HDMI for the given number of channels and is supported by the AVR as well (all channels of that entry must also be present in the EDID speaker allocation block).

In this table the 6.1 entry with RC comes before the 7.1 entry with the (deprecated) RLC/RRC entries, so if your AVR announces support for both RC and RLC/RRC you'll get the former (6.1) channel map

linux/sound/soc/codecs/hdmi-codec.c at 3a8b7204348682152b77618eed061e8718db5935 · raspberrypi/linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at…

github.com

	/* 6.1 */
	{ .ca_id = 0x0f, .n_ch = 8,
	  .mask = FL | FR | LFE | FC | RL | RR | RC },
	/* surround71 */
	{ .ca_id = 0x13, .n_ch = 8,
	  .mask = FL | FR | LFE | FC | RL | RR | RLC | RRC },

It's then up to kodi to decide how to best map the channels of the media file to those channels.

In general it's best to use passthrough for compressed audio formats as this avoids all the channel mapping shenanigans but that may not be an option on RPi2/3 as they don't support TrueHD or DTS-HD because of hardware limitations/bugs (they also can't output 8ch 192kHz PCM).

so long,

Hias

Your log is showing frequent wifi disconnects and reconnects - very likely this is the cause of your issues.

As chewitt already mentioned you have to fix that and likely your problems all will vanish.

If wired lan really isn't an option then use powerline or an external wifi AP configured as a wifi-lan bridge or at least an external wifi dongle (the RPi on-board wifi is known to be quite poor).

so long,

Hias