Posts by chewitt

2025-08-13 19:08:23.604 T:976      info <general>: ffmpeg[0x208aae90]:   Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn (default)

^ media is detected as 4K23.976 (10-bit, with a colourspace normally associated with HDR)

2025-08-13 19:08:23.740 T:979     debug <general>: CRenderManager::Configure - change configuration. 3840x2160. display: 3840x2160. framerate: 23.98.
2025-08-13 19:08:23.745 T:892     debug <general>: DeleteRenderer - deleting renderer
2025-08-13 19:08:23.745 T:892     debug <general>: LinuxRendererGLES: Cleaning up GLES resources
2025-08-13 19:08:23.745 T:892     debug <general>: SetHDR: setting connector colorspace to Default
2025-08-13 19:08:23.745 T:892     debug <general>: LinuxRendererGLES::Configure: fps: 23.976
2025-08-13 19:08:23.745 T:892     debug <general>: SetHDR: setting connector colorspace to BT2020_YCC
2025-08-13 19:08:23.745 T:892     debug <general>: LinuxRendererGLES::Configure: HDR passthrough: on

^ then it flags a renderer with [email protected] and appropriate colourspace, but have you enabled "adjust reresh" ? - If yes it will output using the whitelist (not configured) or best guess at the right mode. If not, it will scale the output to the desktop res (1080@60). So make sure adjust-refresh is enabled and configure the whitelist as per the wiki article.

Once done, if you run kmsprint on the SSH console before playback it will show DRM connector properties as 1080@60, and during playback it should show them to be [email protected]?

Quote from Ozyman

Hope this helps!

Not much. Please repeat after creating a plain SMB mount to the device where you store media, then play something appropriate and 4K from that source using the Kodi 'Videos' view so we can see a playback event containing all the normal and useful ffmpeg/drm/Kodi media debug info that's being masked or suppressed by the Plex plugin you are using. In the log you've captured I can sort of figure out where playback probably occurred, but there's no useful info.

Do we have to guess what OS or distro the other instance of Kodi is running on?

Quote from ghtester

The issue is still the same in LE13.

The issue is still not reported to Tvheadend developers. TL/DR; expect your issue to still remain unresolved.

Quote from chuck

I am surprised and disappointed that they don't have an installer for Linux.

We had this in the past, but to create a single binary that runs on all Linux distros requires Qt to be built from sources in a 'static' config (else users need to install 350MB+ of shared Qt6 packages to run our 3MB app) and the bump to Qt6 (needed for a long list of reasons) required a completely different build command/recipe to the one previously used with Qt5. Nobody on staff ever managed to figure out the new recipe; including several folks that work with Qt6 professionally in their day-jobs. So we have no Linux app.

Should you wish that to change, go find the build recipe.

The "invalid-key" error is something internal to the wireless stack and has nothing to do with "passphrase" for the network. It's root cause is still unknown but poor signal strength is a regular factor in it being seen.

Post the entire log somewhere else there's no point asking upstream devs to comment; it's the first thing they'll ask for.

There must be only one APPEND line in the syslinux.cfg file (with your video= changes) and the boot=UUID= and disk=UUID= details (the UUIDs) must match the UUIDs of the two partitions on the internal drive, use 'blkid' to check them. If you have the wrong UUID details the system will not boot because you told it to use a UUID (partition) that doesn't exist, hence the error message you saw.

The problem description suggests you're trying to set the Kodi desktop resolution to 4K (and users typically pick 4K60) which you probably don't want to do. Have a read here first: https://wiki.libreelec.tv/configuration/4k-hdr

If the device won't switch to any 4K modes (or perhaps modes above 4K30) for playback, the normal cause is HDMI cables that won't support the bandwidth required, or a mismatch between the colour output on the HTPC and input on the TV, e.g. TV only allows 4:2:0 input and you're sending 4:2:2 or some RGB format.

The additional dice-roll on inexpensive Intel devices is that the HDMI outputs are often derived from DP using an LSPCON chip which has its own firmware (can be buggy or needing updates) which influences the capabilities of the HDMI chain as this is cheaper to manufacture than wiring up a dedicated HDMI display transciever on the board. Some users find they need to use the DP outputs with an external DP to HDMI adapter to avoid problems with the internal one. Of course, the external DP to HDMI convertor also has a chip (with firmware) so they are not all equal, but unlike the internal convertor you can order a few different ones from Amazon and then return them if they didn't work.

For some users it all just works fine. Others have a more frustrating experience. We'd love to meet the Intel engineer who first came up with the idea of using LSPCON chips with their NUC designs (which everone has copied since). Preferrably in a dark alleyway so we can thank them properly for all the extra support work and frustration we've encountered since then.

SSH in and run the following commands, then share the URL's generated:

a) Run journalctl | paste

b) Run lspci -nnv |paste

c) Run lsusb -tv | paste

From that we can see info the PCI and USB hardware connected and what happened (or not) during boot, or what's missing.

Have a read here: https://wiki.libreelec.tv/hardware/intel…generic/laptops

It's been reported upstream: https://github.com/xbmc/imagedecoder.heif/issues/76 .. but that doesn't appear to have gotten anyone's attention. If/when/once Kodi bump the add-on we'll pick up the change.

Quote from djon

I just tried installing the latest nightly and also get the Failed to start display.service error

It's harmless, read above.

1080p is the default desktop resolution, read https://wiki.libreelec.tv/configuration/4k-hdr

Intel chipsets are all supported via the same "iwlwifi" driver which is enabled in our kernels. I have no knowledge of the individual chipsets because we rarely see issues reported against them, and when things just work we don't learn about them.

In all three logs "wlan0" is probed and appears to be present, and in the USB logs I also see wlan1 (and confusingly, wlan2) and those are then associating successfully to the network. I don't see any attempts from the wlan0 interface (the Broadcom card) to associate to a network.

Note that ConnMan stores SSID/pass data against a specific card, so even if you have connected successfully on wlan1/2 and then remove the USB card, it will not auto-connect to the network using wlan0. You would need to specifically connect without the USB device connected and (re)enter the passphrase. I'm wondering if you've done that?

That said, I'm also just realising that wlan0 is using the 'wl' driver:

Aug 06 08:25:54 LibreELEC kernel: wl: loading out-of-tree module taints kernel.

This driver is vendor/out-of-tree and has been unmaintained by Broadcom for more than a decade. It has been dropped from LE13 as it no longer compiles and I wouldn't be even slightly surprised if (even when it did compile) it didn't work properly on modern kernels due to long-term bit-rot. Some wl using cards are also supported by 'b43' which although in-kernel, is equally unmaintained for about a decade, and for that reason we haven't enabled it in LE13 kernels after dropping wl. TL/DR; even if this did work on LE12 it will have a short lifespan.

For that reason I'd recommend you get an alternative PCIe card. Look for something with an Intel chip as those are generally well maintained and with the drivers/firmware upstream.

It fails on some add-on packages too. This PR resolves the issue https://github.com/LibreELEC/LibreELEC.tv/pull/10314

Quote from emelsky

However if I reboot LibreELEC without other connection (either wired or USB WiFi) then Broadcom card disappears.

Please run "journalctl | paste" and share the URL generated for three states:

a) Boot with Ethernet connected, USB wifi disconnected

b) Boot with USB wifi connected, Ethernet disconnected

c) Boot with neither USB or Ethernet connected (then wait 60 secs, connect Ethernet to pastebin the log)

config R8169                                                                              
        tristate "Realtek 8169/8168/8101/8125 ethernet support"                           
        depends on PCI                                                                    
        select FW_LOADER                                                                  
        select CRC32                                                                      
        select PHYLIB                                                                     
        select REALTEK_PHY                                                                
        help                                                                              
          Say Y here if you have a Realtek Ethernet adapter belonging to                  
          the following families:                                                         
          RTL8169 Gigabit Ethernet                                                        
          RTL8168 Gigabit Ethernet                                                        
          RTL8101 Fast Ethernet                                                           
          RTL8125 2.5GBit Ethernet

From Linux 6.16 kernel Kconfig options ^ .. the RTL8125 chip is supported by the r8169 driver so 'all' kernels (not some) are using that driver with that chip.

You will need to describe in more detail (and provide system logs) detailing the actual problem. NB: blacklisting r8169 will disable part of the ethernet stack, but not all of it. You will still see the Realtek PHY being probed and detected.