If you want to run Kodi in a container, go find a container that runs Kodi: https://hub.docker.com/search?q=kodi
Posts by chewitt
-
-
I'm using 'black' as the screensaver with a variety of ARM SoC boards since forever and nothing has changed. I'm admittedly using LE13 images for a long time now but when I was using LE12 in the past (and LE12.2 is based on the same Kodi codebase/version) it worked fine. The description of "First couple of seconds it's dark grey, then pitch black" sounds more like the TV having an issue.
-
I'd argue the bug is not strictly adhering to the logic of using DHCP .. OR .. manual configuration, i.e. If you switch from DHCP to manual I would expect that the correct action is forcing the user to (re)define everything from scratch. That's probably an issue with our implementation of a ConnMan agent, and something to fix.
-
The codebases are different, but the kernel media capabilities are essentially the same and largely untouched since 2020.
-
The differences between RK3588 and RK3588S are minor and handled in the upstream kernel for a long time already.
-
a) LibreELEC does not support S928X hardware
b) This is not a forum for recovering Android boxes
c)

-
-
-
I'm not sure if this ^ is the same as the evalation (evb) boards present in u-boot/kernel, but if I was building an image to experiment from that would be my starting point. That said, device-tree changes/improvements to RK boards in the kernel seem to be made on a very individual basis (no bulk enablements etc.) so you may also find the evb files need some fixups; they are inherently often the first board to be added for each SoC type, and then development focus quickly switches to commercially available boards, so the evb boards fall behind current driver capabilities over time.
-
To understand what's happening you'll need to share the serial UART output from u-boot (needs a USB UART cable) and then the kernel or system log.
-
I think I was half-asleep this morning..
-
The issue is nothing more than packaging. Some binaries need to be deleted from build infra, and then rebuilt. No change to the release tag.
-
Someone wrote that it might be a problem with initializing in time.
It's not impossible, but given this is RPi, I'd expect the firmware to be tolerant of that kind of thing.
If it continues to work fine (after reimaging) it's just another random SD card event.
-
What advantages are there using LE 13 nightly on le potato compared to LE 12.2(1) stable?
None. Both are equally unfunctional

-
Make /flash writeable with mount -o remount,rw /flash then edit /flash/syslinux.cfg in nano and append ^ to kernel boot params (put everything on a single line). Reboot with the HDMI cable connected to HDMI-A-1 and see if forcing the initial DRM connector state to 1080@60 solves the problem?
If not, create /storage/.kodi/userdata/advancedsettings.xml with the content below and reboot:
-
SSH in and run ^ after boot. It will dump the initial log to file then tail/append future journal content to the same file. Now go start something playing until it hangs. The logging task will die when the system hangs but the file will remain on-disk after you power cycle and log back in. Then do:
a) cat /storage/journal.log | paste
b) cat /storage/.kodi/temp/kodi.old.log | paste
Share the URL's and if you're lucky there's a trace of something in the system log that correlates to the kodi old log.
-
Update to a current LE13 nightly image from https://test.libreelec.tv/13.0/Generic/Generic/ (scroll down for latest)
If nothing changed, put Kodi in debug mode, reboot, then play something and run "pastekodi" again.
-
I have no advice on brands for these kinds of things, there is too much variation. You can also read the Denon AVR thread, but "Caveat Emptor" applies
