Posts by chewitt

Quote from roctheengy

SBC is now recognized as the Sweet Potato- nice. However, USB doesn't work at all; no USB device work once Kodi starts.

The only issue I see in the log is something to do with spi-nor flash, but I've no idea what that could be. The description above sounds a bit like an inadequate PSU problem. There's no software interaction between Kodi and USB, but starting Kodi will require the GPU and HDMI bits to do something, which increases power draw, which might result in bad behaviour if the PSU is weak. What's the spec of the PSU?

emveepee ?

RPi4 is great but the speed difference between RPi4 and RPi5 is noticeable (once you compare them you won't want an RPi4). Sell the pile of old stuff on eBay to fund an RPi5 + NVME HAT.

Bad curl update, it's already been reverted.

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-CC

That ^ 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.

Quote from AndreaWozzup

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.service

Those ^ 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 set

This 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?