a) LibreELEC does not support S928X hardware
b) This is not a forum for recovering Android boxes
c) ![]()
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 ![]()
The Kodi release manager tagged the 21.3 release ![]()
The same release manager has then paused the push of release notes and wider rollout after noting a minor issue for a couple of the platforms that Kodi ships binaries for. That seems to be taking time; such is the nature of all-volunteer FOSS projects where folk have real-world commitments that need their attention too.
Until something changes, the tagged 21.3 release is still the tagged 21.3 release and Kodi still seems to play movies and tv shows. Go watch something instead of obsessing over release numbers.
There is no need for multiple threads on the same issue so I have merged the latest post into here.
Using the latest log we can see the following:
2025-11-11 19:38:15.112 T:998 info <general>: VideoPlayer::OpenFile: nfs://192.168.192.242/Multimedia/Mediatheken/Serien/Dept. Q/Staffel 1/01 - Folge 1.mp4
...
2025-11-11 20:00:19.722 T:998 debug <general>: HandleKey: play_pause (0xf0bd) pressed, window 12005, action is PlayPause
2025-11-11 20:00:19.762 T:30400 debug <general>: CDVDAudio::Pause - pausing audio stream
...
2025-11-11 20:03:10.152 T:998 debug <general>: HandleKey: play_pause (0xf0bd) pressed, window 10142, action is PlayPause
2025-11-11 20:03:10.153 T:30400 debug <general>: CDVDAudio::Resume - resume audio stream
...
2025-11-11 20:42:00.918 T:30398 debug <general>: CPtsTracker: detected pattern of length 1: 40000.00, frameduration: 40000.000000
2025-11-11 20:42:59.535 T:30398 warning <general>: OutputPicture - timeout waiting for buffer
2025-11-11 20:42:59.957 T:30398 debug <general>: CPtsTracker: pattern lost on diff 0.000000, number of losses 1
2025-11-11 20:43:05.535 T:30398 debug <general>: CPtsTracker: detected pattern of length 1: 40000.00, frameduration: 40000.000000
2025-11-11 20:43:38.703 T:1085 warning <general>: ActiveAE - large audio sync error: -1599.897181
2025-11-11 20:43:38.705 T:1073 debug <general>: CLibInputKeyboard::ProcessKey - using delay: 400ms repeat: 80ms
2025-11-11 20:43:39.063 T:31758 debug <general>: Thread Timer start, auto delete: false
2025-11-11 20:43:39.153 T:1085 warning <general>: ActiveAE - large audio sync error: -2256.463541
2025-11-11 20:43:39.153 T:1085 warning <general>: ActiveAE - large audio sync error: -2257.239806
2025-11-11 20:43:39.445 T:31758 debug <general>: Thread Timer 140212931868352 terminating
2025-11-11 20:43:39.867 T:1086 error <general>: CAESinkALSA - snd_pcm_writei(-32) Broken pipe - trying to recover
2025-11-11 20:43:40.246 T:1085 info <general>: Skipped 1 duplicate messages..
2025-11-11 20:43:40.246 T:1085 warning <general>: ActiveAE - large audio sync error: -3339.997892
2025-11-11 20:43:40.246 T:1085 debug <general>: ActiveAE::SyncStream - average error -1000.000000 above threshold of 100.000000
2025-11-11 20:43:40.306 T:1085 debug <general>: ActiveAE::SyncStream - average error -21.496599 below threshold of 30.000000
2025-11-11 20:43:40.306 T:1085 warning <general>: ActiveAE - large audio sync error: -2408.135241
2025-11-11 20:43:40.306 T:1085 warning <general>: ActiveAE - large audio sync error: -2408.656654
Display More
So playback starts at 7:38p, is paused at 8:00pm, resumed at 8:03pm, then the state tracker goes schizoid at 8:43pm. There is nothing in the log to indicate why, but the most logical explanation is the connection to the media source being interrupted.
Please run "pastekodi" or "journalctl | paste" and share the URL so we can see what the OS is doing around the same time.
Is there a way to run LibreELEC inside a docker container
No. You can virtualise an OS with a hypervisor. You can virtualise an app with a container. LE is an OS, not an app.
So you either install Docker on LE (which exists) and then add (and you support) the containers you need. Or you can run another OS that supports containers and run Kodi via a container (something probably exists). Or you run another OS with a hypervisor and run LE as a guest OS on that hypervisor. An OVA for vmware hypervisors exists for project staff to use for dev work and some users are known to run LE that way. Note that the OVA is unsupported; meaning that all other use of it must be self-supported.
Any idea what I can check to help you?
Push the uncompiled device-tree (dts) file that includes your modifications to a GitHub repo so I can see them. NB: You won't get any meaningful feedback from the systemd service because the setup script is blindly dependent on the compiled dtb. The content in the dtb file is either right and it works, or wrong and it doesn't.