Posts by chewitt

Quote from mibane

As I can read here in the wiki, audio has to work. As the device is currently connected to a standard monitor without speakers, I wonder if this may contribute to all the issues?

Kodi appears to read some HDMI audio capabilities from the DRM driver layer, but the EDID data from the monitor presumably shows no speakers so Kodi ends up running in circles trying and failing to open an audio sink. This eventually fails but only after generating a ton of log noise. It will be more productive (and less log-noisy) to run tests with the TV. You must also run "getedid delete" as the previous inappropriate advice to run it will force the kernel to always see the monitor (with no speakers) attached instead of the TV .. thus guaranteeing bad results.

2025-11-23 12:12:46.454 T:900     error <general>: SMBFile->Open: Unable to open file : 'smb://192.168.178.13/VIDEO/SPIELFILME/JAMES%20BOND/James%20Bond%20007%20-%20In%20t%c3%b6dlicher%20Mission%20(1981).mkv'
                                                   unix_err:'16' error : 'Invalid argument'
2025-11-23 12:12:46.454 T:900     error <general>: CFileCache::Open - <smb://192.168.178.13/VIDEO/SPIELFILME/JAMES BOND/James Bond 007 - In tödlicher Mission (1981).mkv> failed to open
2025-11-23 12:12:46.454 T:900     error <general>: InputStream: Error opening, smb://192.168.178.13/VIDEO/SPIELFILME/JAMES BOND/James Bond 007 - In tödlicher Mission (1981).mkv

The first error looks like Kodi is configured to use the default HDMI device (#0) when the active/connected HDMI device is #2 so the alsa audio sink cannot be opened.

The second error is related to SMB (invalid argument) so check that you are using a valid IP/path and credentials in sources.xml and the SMB protocol versions used by the Kodi SMB client are correct for the NAS.

Chrome (not Chromium) still requires Xorg which is Generic-Legacy. There is no equivalent under the non-Legacy image.

Quote from mibane

Any suggestions are highly appreciated!

Put Kodi into debug mode, reboot, replicate the problem, then share the log via "pastekodi" else we are guessing (none of the info shared thus far is particularly enlightening).

Avahi (ZeroConf) advertises multiple services do the network browser app on Ubuntu etc. will show everything advertised. I'd guess that lowercase is SSH and uppercase is Samba (SMB). The Samba config in LE is oriented towards Windows and IIRC requires auth (libreelec/libreelec, not root/libreelec) so as long as you're using the right credential access should work. If the LE/RPi device is using DHCP it might help to add a static DHCP assigment in the router so the dynamic IP address never actually changes and thus DNS resolution of libreelec.local should also never change (avoids stale mDNS caching issues). Otherwise you need to look at Samba client logs on PopOS (or make connections manually from the console so you see stdout errors) to see why client access has failed.

NB: The perennial issue with RPi hardware and WiFi is that the antenna isn't brilliant and this affects the underlying connection and can introduce misc. errors. If running an Ethernet cable eliminates the issue, WiFi itself is the problem.

mkdir -p /storage/.config/firmware/mediatek
cd /storage/.config/firmware/mediatek
wget https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/mediatek/mt7601u.bin
reboot

It's nothing more than missing firwmare so do the above ^ (watch for the line wrap on the wget command) and it should work?

Confirm back and I'll pick the firmware to future images.

# zidoo v12 remote                                                                        
evdev:input:b0005v5A44p5A44*                                                              
 KEYBOARD_KEY_c0041=enter #OK                                                             
 KEYBOARD_KEY_7003a=l #sub                                                                
 KEYBOARD_KEY_c01bd=i #info                                                               
 KEYBOARD_KEY_7009a=o #tv out                                                             
 KEYBOARD_KEY_c00bc=repeat                                                                
 KEYBOARD_KEY_c006d=c #zoom                                                               
 KEYBOARD_KEY_70045=m #square key with lines                                              
 KEYBOARD_KEY_c01b7=leftquote #audio                                                      
 KEYBOARD_KEY_c00e2=volume_mute #mute                                                     
 KEYBOARD_KEY_c00e9=period #vol-up                                                        
 KEYBOARD_KEY_c00ea=comma #vol-down                                                       
 KEYBOARD_KEY_70027=zero #0                                                               
 KEYBOARD_KEY_7001e=one #1                                                                
 KEYBOARD_KEY_7001f=two #2                                                                
 KEYBOARD_KEY_70020=three #3                                                              
 KEYBOARD_KEY_70021=four #4                                                               
 KEYBOARD_KEY_70022=five #5                                                               
 KEYBOARD_KEY_70023=six #6                                                                
 KEYBOARD_KEY_70024=seven #7                                                              
 KEYBOARD_KEY_70025=eight #8                                                              
 KEYBOARD_KEY_70026=nine #9                                                               
 KEYBOARD_KEY_7002a=backspace #backspace                                                  
 KEYBOARD_KEY_700b7=power #tv out green 

See if that content works?

1. Not unless someone upstreams support for the box to the upstream kernel and u-boot

2. There are nightlies for some RK3576 devices and equivalent test images with marginally newer kernel etc. in my test share

3. LE supports whatever level of 'properly' the current upstream kernel supports

4. If you want things to work 'properly' it will probably need device-specific dts/u-boot. Nothing exists for that device.

In short; there is code and prior-art in our buildsystem and we publish that under GPLv2 so anyone can go nuts and experiment and do whatever they like with it. There are no nicely typed up technical notes or HOWTO guides. You are welcome to ask questsions, but you should have low expectations for anyone spoon-feeding you with instructions on how to author support for your box.

None, and it's not likely to be nearing the top of my to-do list anytime soon due to other priorities.

The Creator app has no code to assign drive letters. That function is solely done by Windows itself when it auto-detects a filesystem on the inserted USB stick. So please direct your pithy ire towards Microsoft who have been authoring that kind of problem for their consumers for about the same lenght of time you've been using computers.

I've no idea what specificially happend or what the underlying Windows problem is, or even what version of Windows you have (seems you are too busy telling stories to give useful facts) but every version since Windows 95 has a 'Computer Management' control panel and this has a filesystems section that allows your to reformat devices and add/change/deletion the current drive letter assignments.

NB: Once you create LibreELEC install media you need to boot from the USB stick and the installer will guide you through the process of installing to an internal drive. Once you select an install target the installer will ask you multiple times to confirm that you want to overwrite and destroy existing content on the drive, but if you keep hitting yes, it will do that. I'm mentioning because you sound like the kind of Windows user whose next post in this forum will be complaining that our installer hosed your entire Windows install.

I'm also going to point out that Kodi has a perfectly good native Windows app, which might be your easiest option.

The config.txt file has 4K60 modes enabled so I'll guess that the HDMI port the TV connects to the AVR on only supports 4K60 4:2:0 input so the AVR advertises this to the downstream RPi4 which does not support 4K60 4:2:0 output; so the RPi4 cannot negotiate a valid 4K HDMI mode and Kodi is forced to start 'offscreen' and you see a blank screen instead of the Kodi home screen.

Switching the HDMI input on the TV to a port that supports 4:2:2 input or changing port properties to allow 4:2:2 input will be the best fix. You can also add video=HDMI-A-1:1920x1080M@60D to kernel boot params in cmdline.txt to force the initial DRM connector state to 1080@60 instead of 4K to get the Kodi home screen showing; but this will not fix the underlying 4K handshaking issue if/when you try to play 4K media.

NB: This wiki article has some general notes on setup: https://wiki.libreelec.tv/configuration/4k-hdr

Have you enabled 3:2 pulldown in Kodi video settings?

Quote from nosen

One, I want to use the stable branch so that I don't have to deal with stability problems, and two, I think it's useful to keep debugging this so we may identify the bug, and stop it from popping up again later.

I've been running self-built LE13 nightlies for the last ~2 years and the only time they have been unstable is when I've been doing intentional experimenting of my own, but even that's been low drama. The nature of the LE 12.2 release means it's prob. received considerably less staff runtime testing than LE13 nightlies; but hey, users do obsess over the 'stable' label.

As you're the single LE user reporting the problem and there appears to be a valid workaround I have low interest in chasing the problem on LE12.2 .. esp. when you're already trying to pass the buck and avoid doing the test I've already suggested that might narrow the scope of the problem. The differences between LE12.0 and LE12.2 are too large to do anything but guess, and even if something was obvious the solution is unlikely to go into an LE12.2 image (as there isn't expected to be another release) so the fix would be in LE13 (which doesn't appear to need one).

Quote

I want to be crystal clear: the bug only manifests on a small subsection of content, namely live tv i.e. the same thing you'd see on the regular terrestial broadcast

That ^ wasn't fully obvious in the original report (and perhaps not to the GitHub thread either). Kodi is essentially a big fancy wrapper around ffmpeg's capabilites for playback, and since the kernel and ffmpeg versions/patches in LE12.2 and LE13 are the same, I'd still be thinking about config and behaviour of the add-on more than the OS.

LE12.2 is a fork of the LE13 codebase from a couple of months back retrofitted with K21 not K22, and notably with the same ffmpeg version used in both. So if you want to play 'spot the difference' there's more in-common between the LE12.2 and LE13 than there is between LE12.0 and LE12.2 (and that difference is too large to spot anything). Combine that with the add-on working for multiple users with non geoblocked content on both releases and my suspicions are towards add-on config or something environmental not an issue with the base OS; and hence the suggestion to test that theory.

Nothing changed. Kodi allows you to create different profiles and to use a remote DB to store library and some (but not all) config data. However there is no concept of roaming profiles or a Kodi-internal way to keep data synchronised over multiple devices. You always need some form of external-to-Kodi sync, and being 'external' this inherently runs into data consistency issues.

Quote from nosen

Clean image of 13.0 20251117 nightly. Interestingly, the glitch is not present on this version.

Now start adding back add-ons and config from the other install piece-by-piece until you either end up with a fully configured system, or you find the add-on or config step that breaks things.

I would start by creating a clean image without all the conf file fiddling that your current ones contain. As long as the TV provides valid EDID data on the HDMI cable, HDMI audio works in the default config and no additonal config is required. Check cables; if using adapters ditch them and get a proper micro-HDMI to HDMI cable.

The ffmpeg version used with Kodi supports software decoded H264 on RPi5 without issues and transcoding is not relevant to the problem. Our usersbase is ~80% RPi boards and if there were fundamental issues with H264 we'd have a thousand forum posts on the topic.