Posts by heitbaum

It will be released as 13.0 when Kodi 22 (Piers) is released.

Until then we will continue to improve, update the components making up the operating system in preparation.

There is not enough information in the above report to understand or investigate the issue. Good that you were testing with the current release of LE. The Intel drivers (and graphics and audio and kernel) are the current releases, so would suggest that you will need to compare what versions and what compilation differences are between the Ubuntu and LE release. The Ubuntu 24.04 image will likely have down rev packages. Kernel, Firmware GuC and HuC, XE driver are all likely to play a part if the other packages are the same versions. I’m assuming that you are compiling the same Kodi version on Ubuntu with the same settings as LE and running without a window manager.

The Intel drivers, firmware, kernel in LE are most likely newer than the Ubuntu ones if using the LE13 nightlies - you should confirm that you are using recent ones (202512 or 202601 images). Using a LE12 image on recent AMD or Intel hardware will miss out on all recent hardware additions.

That being the case (if it is a current LE image that was tested) then there is likely to be some other difference in the platforms that is causing issue (a kernel option, a firmware module, a compile difference, a required software component.) The xe driver works well but I only test it with the iGPU.

The image you are using is a previous release of LE13. Please update to the current release to be able to install addons. The current addon releases are 12.80.5. You will be able to find the current LE13 images at - https://test.libreelec.tv/13.0/

Not sure the version you are referring to. The addon versions are (depending if you are running LE12.2 or LE13):

- 22.3.6-Piers

- 21.5.18-Omega

Please share the logs if still an issue.

Quote from sparkplug

Some of my add-ons need inputstream-adaptive ..The way I see to install it is with apt. However Libeelec does not have apt.

Any help is appreciated.

Its available as an addon

edid-decode is added at our mirror.

For kmscube - the hash has changed at the source.
- I have created the PR to fix this.

- in the mean time please run.

CHANGE_HASH=yes scripts/get kmscube

--- a/packages/graphics/kmscube/package.mk
+++ b/packages/graphics/kmscube/package.mk
@@ -3,7 +3,7 @@
 
 PKG_NAME="kmscube"
 PKG_VERSION="9f63f359fab1b5d8e862508e4e51c9dfe339ccb0"
-PKG_SHA256="896ac76671a9b89836a7014b16cc85b45b041e03fe34a8f529f4718aa2b15cef"
+PKG_SHA256="6f5a56929e8958e8e0d073c898c0d50d3c6ab7f070ad0d2f185a6ee2d29b57d7"
 PKG_LICENSE="GPL"
 PKG_SITE="https://gitlab.freedesktop.org/mesa/kmscube"
 PKG_URL="https://gitlab.freedesktop.org/mesa/kmscube/-/archive/master/kmscube-${PKG_VERSION}.tar.gz"

I have added grub file to the mirror server

Issue identified, mpd rebuilding now.

That error is from an old mpd.

as below for the current mpd.

# wget https://addons.libreelec.tv/12.80.5/Generic/x86_64/service.multimedia.mpd/service.multimedia.mpd-12.80.5.1.zip
# unzip service.multimedia.mpd-12.80.5.1.zip
# service.multimedia.mpd/bin/mpd
exception: No configuration file found
# ldd service.multimedia.mpd/bin/mpd | grep avutil
libavutil.so.60 => /usr/lib/libavutil.so.60 (0x00007f073fd53000)

please update to the latest mpd addon

Quote from tetienne

I fear armbian or debian will not provide any relevant clue if they do not run kernel >= 6.17

Note there was a change in 6.17 around the pmdomain - see the history on https://github.com/LibreELEC/Libr…rojects/Samsung and its reference to rebasing the patches applied to the kernel.

tetienne unsure what state you have your Samsung in? What changes were required? Are you saying that an image with 6.16.0 works but 6.16.1 fails? What are the logs? Does 6.18 work? SD is the place to start. You would need to share the uboot uart logs of the emmc boot? What uboot is being used?

Ok - think we have identified the issue.

Set iptables -P FORWARD ACCEPT back to iptables -P FORWARD DROP

- you are using a custom bridge.

- docker network ls

- iptables --list-rules

I expect your lines to look like the first two.

-A DOCKER -d 172.21.0.2/32 ! -i br-6b309bd08e7c -o br-6b309bd08e7c -p tcp -m tcp --dport 80 -j ACCEPT
-A DOCKER -d 172.19.0.2/32 ! -i br-edb5b4325218 -o br-edb5b4325218 -p tcp -m tcp --dport 80 -j ACCEPT
-A DOCKER -d 172.17.0.6/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 80 -j ACCEPT
-A DOCKER -d 172.17.0.5/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 9999 -j ACCEPT

If you then ran (br-… to match your above)

iptables -A DOCKER-BRIDGE -o br-6b309bd08e7c -j DOCKER

I would expect it to work.

Not sure on the root cause or the right fix (for custom networks) but for the default docker0 network, you should not be having the problem.

Please run iptables -P FORWARD ACCEPT and let us know.

Looks to be ipv6 traffic not passing.

ip6tables --list
iptables --list

On my system show the docker chains in both. I have connectivity from the docker containers.

You need 20251128-85c6ad7 or greater for nft

Can you please confirm you are running 20251128-85c6ad7? Versions before this will not have the libraries.

cat /etc/os-release