Posts by adam.h.

Grok4 went and got itself some extra neurons, so here’s its hot takes. Might not be complete trash, who knows?

Grok4:

From the system details you provided (which appear to be from a Ubuntu-like distro, not LibreELEC, based on the kernel version and module list), the hardware is detected:

• Touchscreen: Goodix capacitive over I2C (driver: goodix_ts.ko).

• Accelerometer: MXC4005 (driver: mxc4005.ko).

• Both modules are loaded in your current setup, but if they're not functioning (e.g., no input events), it could be due to missing firmware, I2C bus probing issues, or calibration.

LibreELEC's filesystem is read-only (squashfs), so you can't simply "install" drivers like in a full distro. Instead, you'll need to build a custom LibreELEC image with the drivers enabled in the kernel. This is straightforward if you follow the steps below. I'll assume you're starting from a clean LibreELEC install on your device (download the Generic-x86_64 image from libreelec.tv/downloads and boot/install via USB). If you're currently on Ubuntu, switch to LibreELEC first for testing.

Step 1: Verify Hardware Detection in Stock LibreELEC
Before building custom, test if the drivers are partially working in a standard LibreELEC install:

1. Install LibreELEC 12.x (or latest nightly) Generic x86_64 on a USB drive or your internal storage (eMMC via /dev/mmcblk0).

1. Boot into LibreELEC and enable SSH (Settings > LibreELEC > Services > SSH).

1. SSH in (default user: root, password: libreelec).

1. Check for devices:

• Code

  lsmod | grep goodix

  (for touchscreen).

• Code

  lsmod | grep mxc4005

  (for accelerometer).

• Code

  dmesg | grep -i goodix

  and

  Code

  dmesg | grep -i mxc4005

  for load errors.

• Code

  evtest

  to list input devices and test touch/accel events (if evtest isn't available, it's because these modules aren't in the stock image).

• Code

  i2cdetect -l

  to list I2C buses; then

  Code

  i2cdetect -y <bus_number>

  (try buses 0-3 based on your serial controllers) to see if the Goodix (usually at address 0x5d) or MXC4005 (address 0x15) shows up.

If the modules aren't present (likely), proceed to custom build.

Step 2: Build Custom LibreELEC with Drivers Enabled
You'll need a Linux build host (e.g., Ubuntu 22.04+ VM with at least 4 cores, 8GB RAM, 50GB free space). This enables the drivers as kernel modules.

1. Set Up Build Environment:

• Install dependencies:
  
  Code

  sudo apt update && sudo apt install git gcc g++ make ncurses-dev bc lzop libssl-dev flex bison qemu-utils java-runtime-headless dosfstools

  .

• Clone LibreELEC repo:
  
  Code

  git clone https://github.com/LibreELEC/LibreELEC.tv.git

  .

• Checkout the branch for your version (e.g.,
  
  Code

  cd LibreELEC.tv && git checkout 12.0

  for stable, or master for nightly).

1. Enable the Drivers in Kernel Config:

• The kernel config is in
  
  Code

  packages/linux/linux.conf

  (for Generic x86_64).

• Edit
  
  Code

  packages/linux/package.mk

  to add a patch for config changes.

• Create a patch file
  
  Code

  packages/linux/patches/linux-0001-enable-goodix-mxc4005.patch

  with contents:

--- a/.config
+++ b/.config
@@ -XXXX +XXXX @@  # Find the IIO/INPUT sections via `grep` in the config
# CONFIG_TOUCHSCREEN_GOODIX is not set
+CONFIG_TOUCHSCREEN_GOODIX=m
# CONFIG_MXC4005 is not set
+CONFIG_MXC4005=m
# Ensure dependencies:
+CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_IIO=y
+CONFIG_IIO_BUFFER=y
+CONFIG_IIO_TRIGGER=y
+CONFIG_I2C_HID=y  # For Goodix HID mode if needed

• Replace
  
  Code

  XXXX

  with actual line numbers—extract the default config first by running a partial build (see below) and checking

  Code

  build.LibreELEC-Generic.x86_64-*/linux-*/.config

  .

1. Build the Image:

• Run:
  
  Code

  PROJECT=Generic ARCH=x86_64 make image

  .

• This takes 1-2 hours. Output is in
  
  Code

  target/

  (e.g., LibreELEC-Generic.x86_64-12.0.0.img.gz).

• Write the .img to USB:
  
  Code

  dd if=LibreELEC-Generic.x86_64-12.0.0.img of=/dev/sdX bs=4M conv=fsync

  (replace /dev/sdX with your USB device).

1. Install and Test:

• Boot the custom image on your GOLE2 Pro.

• SSH in and load modules if not auto-loaded:
  
  Code

  modprobe goodix_ts

  and

  Code

  modprobe mxc4005

  .

• Check
  
  Code

  dmesg

  for errors. If Goodix fails with firmware issues, it may need a binary firmware blob—copy from your Ubuntu setup (

  Code

  /lib/firmware/goodix_*.bin

  ) to

  Code

  /storage/.config/firmware/

  in LibreELEC and reboot (per LibreELEC wiki).

• Test touch:
  
  Code

  evtest /dev/input/eventX

  (find the Goodix event).

• Test accel:
  
  Code

  evtest /dev/input/eventY

  or

  Code

  cat /sys/bus/iio/devices/iio:device0/in_accel_x_raw

  (adjust device number).

Step 3: Enable Touch in Kodi

• Kodi supports touch natively, but ensure:

• Settings > Interface > Skin > Configure skin > Enable touchscreen mode.

• If calibration is off, use
  
  Code

  ts_calibrate

  (if available) or edit

  Code

  /storage/.kodi/userdata/guisettings.xml

  for touch params.

• For multi-touch gestures, it should work once the driver is loaded.

Step 4: Enable Auto-Rotation (Flip)

• Accelerometer provides orientation data via IIO.

• LibreELEC/Kodi doesn't auto-rotate by default (no desktop manager like GNOME).

• Install the "Screen Orientation" addon from Kodi repo (if available) or script it:

1. SSH in, install Python if needed (via unofficial addons or custom build).

1. Create a script
   
   Code

   /storage/.kodi/userdata/autoexec.py

   :

import xbmc
import subprocess
import time
while True:
   try:
       with open('/sys/bus/iio/devices/iio:device0/in_accel_z_raw', 'r') as f:  # Adjust path/device
           z = int(f.read())
       if z > 500:  # Threshold for upright/flipped; calibrate based on your tests
           subprocess.call(['kodi-send', '--action="SetGUIOrientation(0)"'])  # 0=normal, 2=180 deg flip
       else:
           subprocess.call(['kodi-send', '--action="SetGUIOrientation(2)"'])
   except:
       pass
   time.sleep(1)

• This monitors accel and flips Kodi's GUI. Test thresholds with
  
  Code

  cat /sys/bus/iio/devices/iio:device*/in_accel_*_raw

  .

• For GBM rotation, if needed: Edit
  
  Code

  /flash/extlinux.conf

  to add

  Code

  video=DSI-1:panel_orientation=upsidedown

  or similar, but test.

Troubleshooting

• If I2C not probing: Add kernel params in
  
  Code

  /flash/extlinux.conf

  (append line:

  Code

  i2c_dev i2c_hid.polling=1

  ).

• Build errors: Check logs in
  
  Code

  build.LibreELEC-*/

  . If kernel patch fails, manually edit the config during build (pause at menuconfig:

  Code

  PROJECT=Generic ARCH=x86_64 ./scripts/build linux:menuconfig

  ).

• If modules load but no events: Check ACPI tables (
  
  Code

  acpidump

  ) for HID overrides; might need a DSDT patch (advanced).

• Performance: N5095 has UHD Graphics; enable VAAPI in Kodi for hardware decoding (Settings > Player > Video > Allow hardware acceleration - VAAPI).

• Community: Post your build logs on the LibreELEC forum (your recent thread there is a good start) for x86-specific help.

If this doesn't resolve it, provide dmesg output from LibreELEC.

Just in case you don't want to re-invent this wheel: Best Kodi-capable Media Players in 2025 for Video Playback

Did you notice that several builds are picking up the same commit hash? Is it normal? Few examples:

LibreELEC-Generic.x86_64-13.0-nightly-20250626-c1e526c.img.gz (sha256)	2025-06-26 17:08	279.7M
LibreELEC-Generic.x86_64-13.0-nightly-20250627-c1e526c.img.gz (sha256)	2025-06-27 09:57	279.7M
LibreELEC-Generic.x86_64-13.0-nightly-20250628-c1e526c.img.gz (sha256)	2025-06-28 07:18	279.7M
LibreELEC-Generic.x86_64-13.0-nightly-20250628-e7d7252.img.gz (sha256)	2025-06-28 23:25	279.7M
LibreELEC-Generic.x86_64-13.0-nightly-20250630-fa3ad4b.img.gz (sha256)	2025-06-30 16:49	279.7M
LibreELEC-Generic.x86_64-13.0-nightly-20250701-fa3ad4b.img.gz (sha256)	2025-07-01 15:58	279.7M

Quote from chewitt

Code

kernel: nvidia-modeset: ERROR: GPU:0: Timed out waiting for core channel idle.

No idea what that is .. Google doesn't show anything useful.

ChatGPT :

1. Check Kernel Compatibility

The 6.12 kernel may be ahead of NVIDIA’s QA validation curve. Try running with a more conservative, supported kernel version like 6.6.x LTS or 6.7.x to verify stability.

2. Patch the NVIDIA Kernel Module for Compatibility

If you must use 6.12, verify that the DKMS or manual installation succeeded without warnings. Run:

dmesg | grep -Ei 'nvidia|gpu'
dkms status

Check /var/lib/dkms/nvidia/570.144/build/make.log for errors. If there are symbol mismatches or KMS hook issues, NVIDIA may not yet support 6.12, and you may need to:

• Use a community patch set (e.g., from NV-Kernel-Patcher if using open kernel modules)
• Or manually adapt the build if the symbol changed (common with drm API updates).

3. Test Disabling DRM KMS for Isolation

Set in modprobe:

echo "options nvidia-drm modeset=0" | sudo tee /etc/modprobe.d/nvidia.conf
sudo update-initramfs -u

Reboot and see if the timeout disappears. This will narrow the issue to modeset interaction with the new kernel's DRM layer.

4. Enable Early KMS Logging

For deeper kernel debugging, append this to your GRUB:

GRUB_CMDLINE_LINUX_DEFAULT="nvidia_drm.modeset=1 nvidia.NVreg_RegistryDwords=RmLogonRC=0xff" 

Then run:

sudo update-grub && reboot

Watch dmesg output for RmLogonRC flags — this can help pinpoint which channel stalls.

5. Run with Open Kernel Modules (Optional)

Since R515, NVIDIA supports open kernel modules:

modinfo nvidia | grep filename

============================================================================================================
============================================================================================================
============================================================================================================

and here some suggestions tailored to LE nighties (I'm wondering how much it all makes sense) :

1. Add NVIDIA DRM Modeset Boot Option

LibreELEC lets you append kernel params via cmdline.txt on the /flash partition (accessible from SSH or directly from the SD card/USB):

nvidia_drm.modeset=0

💡 Purpose: Disables DRM modesetting which causes timeout in some nightly builds.

Quote

✅ Highly recommended as first fix to isolate the nvidia-modeset stall.

2. Force Legacy Rendering Path (X11 instead of GBM) — if available

Some builds may allow fallback to X11 rendering using the x11 variant of the NVIDIA driver.

From SSH, check if GBM is active:

cat /var/log/Xorg.0.log | grep -i nvidia
cat /run/libreelec/debug/udev.log | grep -i gbm

If GBM + KMS is the cause, switching to legacy X11 (if supported in this build) can reduce stalls — but not all LibreELEC nightlies retain this support.

3. Check for Nouveau Conflicts

Even though LibreELEC is minimal, you can verify nouveau isn’t mistakenly loaded:

lsmod | grep nouveau

If present, blacklist it permanently via /flash/syslinux.cfg or /flash/extlinux/extlinux.conf (depends on build):

append boot=UUID=... quiet modprobe.blacklist=nouveau

4. Set NVIDIA Power Management Policy

Add to your cmdline.txt (or bootloader config):

nvidia.NVreg_EnableGpuFirmware=0 

In some cases, firmware-based runtime power management causes timing problems on newer kernels.

5. Enable Persistenced (if supported)

LibreELEC often omits nvidia-persistenced, but if present:

systemctl start nvidia-persistenced

If not present, ignore — this is only effective in systems that use persistent GPU state management.

Anyways, this is how it works currently:

Quote from Albert

I still haven't found a solution to this problem.

I had opposite problem with subtitles, always wanted to have original audio but specific subtitles language plus ignore forced subtitles if exists - ended up with creating my own little plugin for this

Anyways, if current (updated) settings in Kodi aren't working for you, you can install Language Preference Manager plugin, which has zillion of options so some settings here should fix your problem.

Quote from chewitt

If you want more changelog info please go look at the full/original commit log on GitHub. We have no plans to bloat page load times and increase webserver load with more commit data that likely few people read.

Yeah, right - we are listing as for now 145 build images (starting from May 2024) and only 20 past commits, no bloating at all, just perfect excuse for someone not getting work done?

Nah, that would be just stupid to keep both in sync (say past 20 builds + 20 commits)

yeah, go for new hw

You can always install EXT4 driver on Windows laptop.

Quote from Marcin

Is force mounting going to fix errors from LE?

It won't fix anything, just mount it regardless these errors. The other (maybe better) option is to fix the disk in Windows system and change LE to mount it always as RO (the above url to autostart is good reference for details).

BTW, the option to mount external contents disks as RO could be good extension for LE, but perhaps it happens so rarely that it is not worth the effort. I'm using RPi5 with latest LE12 and SSD disk formatted as NTFS and while I had that "dirty disc" errors in the past (probably around LE10 or LE9), it works now without problems. So this could be also some combination of disc type, NTFS and LE version (driver version).

There is force mount option in ntfs3, so you could eventually give it a try - not sure what is now the best way to add it for default options in LE, perhaps via autostart as described here.

`````sudo mount -t ntfs3 -o force /dev/sda1 /media/ext

Oh sure, just be patient enough and all the problems will magically solve themselves! 😀

With the following nightly LE release I can play above stream without problems:

 Starting Kodi (22.0-ALPHA1 (21.90.700) Git:db813bfaec3b3bd510e084158fec3ad7be7557a2). Platform: Linux x86 64-bit
 Using Release Kodi x64
 Kodi compiled 2024-10-02 by GCC 14.2.0 for Linux x86 64-bit version 6.11.0 (396032)
 Running on LibreELEC (community): nightly-20241002-a95d055 13.0, kernel: Linux x86 64-bit version 6.11.0
 FFmpeg version/source: 6.0.1
 Host CPU: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz, 8 cores available

 CAddonMgr::FindAddons: inputstream.adaptive v22.1.4.1 installed
 CAddonMgr::FindAddons: inputstream.ffmpegdirect v22.0.1.1 installed
 CAddonMgr::FindAddons: inputstream.rtmp v22.0.0.1 installed
 CAddonMgr::FindAddons: kodi.binary.instance.inputstream v3.3.0 installed
 SECTION:LoadDLL(/storage/.kodi/addons/inputstream.adaptive/inputstream.adaptive.so.22.1.5)

 CAddonMgr::FindAddons: repository.slyguy v0.0.9 installed
 CAddonMgr::FindAddons: script.module.slyguy v0.85.23 installed
 CAddonMgr::FindAddons: slyguy.dependencies v0.0.22 installed
 CAddonMgr::FindAddons: slyguy.disney.plus v0.17.3 installed

However someone with fresh eye catched up that it originally failed on HEVC stream and now it is openning H264 stream, so perhaps Kodi in this version has different preferences - not sure if H264 stream was available originally or was added later by Disney...

I'm just pointing out that it would be more useful to keep in sync releases with changelog info, but perhaps this is just me trying to make some sense out of it.

I'm not asking for more work from developers, just as in the attached example - if we show URLs to around 70 nightly releases, why not make Changelog table also showing 70 pull requests instead of last 18 like currently? I suppose this is some simple update to script rendering these pages?

Guys, could you make the changelog table a bit longer to cover all available nightly builds? For example, in Generic LE13, I have builds from May to September, but the changelog only shows releases from mid-July.

I discovered that LE13 01416e0 is not handling subtitles properly, so I had to downgrade to a randomly chosen build from July 20, as the latest changelog entry only shows releases from July 25.

I know I could spend time looking directly on GitHub, but why not make these pages a little more useful?

After quick discussion with addon creator and ISA maintainers finally I opened Kodi ticket for this...

Some more forensic analysis

Here are the stream properties:

General
Complete name                            : Machine Gun Kelly’s Life in Pink.mp4
Format                                   : MPEG-4
Format profile                           : Base Media
Codec ID                                 : isom (isom/dby1/iso2/mp41)
File size                                : 2.29 GiB
Duration                                 : 1 h 41 min
Overall bit rate mode                    : Variable
Overall bit rate                         : 3 219 kb/s
Frame rate                               : 23.976 FPS
Movie name                               : Machine Gun Kelly’s Life in Pink
Description                              : 'Machine Gun Kelly’s Life in Pink'
Recorded date                            : 2022
Writing application                      : Lavf60.3.100
Cover                                    : Yes

Video
ID                                       : 1
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main [email protected]@Main
Codec ID                                 : hvc1
Codec ID/Info                            : High Efficiency Video Coding
Duration                                 : 1 h 41 min
Bit rate                                 : 2 958 kb/s
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 10 bits
Bits/(Pixel*Frame)                       : 0.134
Stream size                              : 2.10 GiB (92%)
Title                                    : BAMTech video
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709
Codec configuration box                  : hvcC

Audio
ID                                       : 3
Format                                   : E-AC-3
Format/Info                              : Enhanced AC-3
Commercial name                          : Dolby Digital Plus
Codec ID                                 : ec-3
Duration                                 : 1 h 41 min
Bit rate mode                            : Constant
Bit rate                                 : 256 kb/s
Channel(s)                               : 6 channels
Channel layout                           : L R C LFE Ls Rs
Sampling rate                            : 48.0 kHz
Frame rate                               : 31.250 FPS (1536 SPF)
Compression mode                         : Lossy
Stream size                              : 186 MiB (8%)
Title                                    : BAMTech audio / English
Language                                 : English
Service kind                             : Complete Main
Default                                  : Yes
Alternate group                          : 1
Dialog Normalization                     : -29 dB
compr                                    : -0.28 dB
mixlevel                                 : 105 dB
roomtyp                                  : Small
dialnorm_Average                         : -29 dB
dialnorm_Minimum                         : -29 dB
dialnorm_Maximum                         : -29 dB

Suprisingly it plays well from the file, even with enabled vaapi, and the same content fails with vaapi when it is streamed. See attached 2 screenshots from playing file and playing the stream.

So perhaps the problem is not really in ffmpeg or drivers/kernel, but somewhere between InputStream Adaptive / Disney+ Addon / FFMpeg?

EDIT: I forgot to add log file.

Ok, so to complete this journey here is the log with Linux version 6.10.0-rc3 and FFmpeg version 6.1.1, the stream is not playable when hardware acceleration is enabled.

Let me know if you think I can contribute with anything else.