Please put Kodi debug mode, reboot so we capture a clean log, then play Jellyfish 10-bit HEVC test media (not pirated files), then pastebin the entire log (not snippets) with "pastekodi" and share the URL generated so we can understand the host more.
Also share the full debug log from the Arch box too, assuming it's also using a current/recent version of Kodi. Info on the graphics stack there (versions etc.) would be interesting.
It's probably an issue with a change the curl package. It's already been reverted so you can roll back to an earlier nightly or wait until tonights images are built and published.
It's unlikely that Avahi services have anything to do with a crash triggered by plaback of streams from an IPTV source.
Start with an update to a current LE13 nightly so you're using something under active development. Any change?
[ 0.000000] Machine model: Libre Computer AML-S905X-CCThat ^ confirms you are booting the wrong device-tree file. Just edit extlinux.conf to use meson-gxl-s905x-libretech-cc-v2.dtb and reboot. Working now?
Update to the AMLGX image from https://chewitt.libreelec.tv/testing/ as this contains 6.13 kernel and minor fixes. Please also ensure that extlinux.conf is edited to use meson-gxl-s905x-libretech-cc-v2.dtb as the current lepotato image defaults to meson-gxl-s905x-libretech-cc.dtb which is similar enough that the board will boot, but does contain some differences. As you commited the sin of providing a log snippet (always provide a full log) I wasn't able to see what device-tree was being used.
Assuming it's not something simple like using the wrong device-tree? .. create /storage/.config/autostart.sh with the content below and it will dump the systemd journal to disk 2 mins after booting:
(
sleep 240
journalctl -b 0 --no-pager > /storage/journal.log
cp /storage/.kodi/temp/kodi.log > /storage/kodi.log
)&You can then reboot and SSH in while things still work to run cat /storage/*.log | paste and share the URLs generated.
Don't know if this is the same issue
The original thread is discussing the SMB client in Kodi and you're talking about the Samba server in the OS, so I've moved your post into its own thread. Start with an update to a current LE13 nightly as we're unlikely to fix anything in the LE12 codebase now.
How was the controller connected .. using the GUI or bluetoothctl?
What's the range/distance between board and controller?
Is the board in a case? - If yes, what happens when you remove the board from the case?
Update to an LE13 nightly (they are not unstable at this point in the dev cycle, I've been running them for ages).
Have you looked on eBay UK?
systemctl stop pulseaudio.service
systemctl disable pulseaudio.service
systemctl mask pulseaudio.serviceThose ^ commands will workaround the pulse problem, but it shouldn't happen on a clean install. It would be useful to see the URL/output of "pastekodi" with Kodi debug mode to see if there's more info or clues to the cause.
You can use the bluetoothctl utility over SSH to pair/connect devices. If it works there, the issue resides in the LE settings add-on. If it also fails there, it's either a bug in BlueZ or something funky about pairing the device.
For kicks, check the 12.0.2 release and/or the latest LE13 nightly.
Have you tried updating the existing install instead of reinstalling? .. our general advice is to clean install when making large OS/Kodi bumps but all you really need to do is stop Kodi and rename /storage/.kodi to /storage/.kodi-old so the post-update Kodi starts with a clean config and no Python2 add-ons installed.
Kodi on Android has massively improved in recent years, driven by Kodi forcing and adopting Google standards, and this reflects in general usage stats (Team Kodi doesn't track active installs, but we see download volumes and forum traffic). The weak link is thus the underlying Android kernel codebase for any particular vendor and/or device combination, and how it implements or ignores those standards. If the device follows standards, Kodi runs well. If it includes lots of hacks to make specific apps (that don't follow standards) work better, that often degrades the experience of other apps. TL/DR: there's not really an answer, but you can install and try for $free.
Add "ssh" to kernel boot params and the daemon is forced on during boot so you can login, then "journalctl | paste" to pastebin the system journal.
Just boot from the SD card. The OS runs in RAM so while there is a difference in I/O speeds, it's not that significant.
warning <general>: Failed to get an OpenGL context supporting core profile 3.2, using legacy mode with reduced feature setThis is a warning not an error/failure. It simply documents that the GPU doesn't support Core 3.2, but the minimum requirement for Kodi is 2.1 which this site confirms is more than covered: https://people.freedesktop.org/~imirkin/glxinfo/#v=Mesa%2018.0.0. The site is not updated for current mesa (23.x) but generally things don't regress much.
I've tested 12.0.2/340.108 in the last week when poking Nouveau and it worked fine with my GT520 card. That points towards it being an issue with older cards. If it also doesn't work with Slackware, that also points towards a driver issue and not something to do with distro build/packaging.
The kodi debug log isn't useful here as the issue resides lower in the software stack. Was anything recorded in the system journal?
Really dont know how to do the "dmesg | paste" sorry.
You managed to type "dmesg" and hit enter. All you had to do was type "dmesg | paste" and hit enter.
[ 1.543265] mmc1: Card stuck being busy! __mmc_poll_for_busy
[ 1.544665] mmc1: Failed to initialize a non-removable cardThe eMMC storage fails to init ^ and thus isn't visible to the OS, so cannot be addressed. No idea what the underlying issue is, but normally the issue with Android boxes (not specifically WP2) is the chips go bad and throw errors. On the upside, it's failed but still allows SD card boot, which is better than starting to boot and not being able to continue (which can also happen).
The WP2 "board" image you are using cannot boot with the factory Android u-boot on EMMC, so either you wiped/zero'd EMMC to use the image, or the EMMC chips have failed which means the OS cannot detect Android u-boot; thus allowing it to boot upstream u-boot from the SD card.
I'd guess the EMMC chips have gone bad. Share the URL from "dmesg | paste" and we can probably confirm.
RPi4/5 have a single i2s audio interface input, and a single audio driver that supports multiple cards, each with an HDMI connector, and the driver can route audio to either or both cards. The labelling is correct and clear; but alsa is one of the Linux "dark arts" as the terminology (and topology) of things is particularly challenging to understand.