Posts by chewitt

The log contains a prominent kernel splat from the iwlwifi driver and Google (re)searching on that throws up a large number of bug reports from a large number of distros over a long period of time. I didn't find anyone really getting to the bottom of things but the recurring theme is "PCI issues" and some users report success when disabling some features of the kernel driver.

I'd suggest updating to the latest BIOS/firmware for the board then retesting with an LE13 nightly dating from tomorrow (as this will have the Linux 6.18 kernel update merged earlier today).

If that doesn't magically solve anything, something like this might be needed https://www.edu4rdshl.dev/posts/fixing-i…ashes-on-linux/

Two things to try:

a) Run "getedid delete" then add video=HDMI-A-1:1280x720M@60D to kernel boot params and use the HDMI port nearest to the PSU connector. This forces the initial kernel DRM state of the connector to 720p output which sometimes resolves handshaking issues.

b) Run "getedid delete" (to remove the possibly bad van EDID) and connect to the working monitor and run "getedid create" then power up with it connected to the van and see if anything shows up on the display?

Quote from ghusto

Libreelec is not an embedded system, and "we" can take advantage of that fact

I've quoted the "we" for emphasis ^

Kodi devs made a serious proof-of-concept for a Kodi-internal browser 3-4 years ago. This proved that it was a non-trivial feature to bring to Kodi. The prototyping showed a mountain of platform-specific code was needed (Kodi supports 6+ platforms) and it would also need frequent updates to manage the inherent security issues of a browser; the underlying browser engine (Chromium) is in a state of constant change for the same reason. The team concluded that adding a browser is technically possible, and we all see the value of having one, particularly to ease the challenge of accessing streaming platforms. However the overall level of effort required to implement and then maintain an in-Kodi browser doesn't align with how Kodi is [under]staffed since forever or the anarchic way the project operates itself.

Quote from ghusto

I feel a lot of hostility towards actual users when they have reasonable requests like this.

I'm normally aiming for sarcasm more than hostility, but "we" get bored of new users showing up and expecting us to treat their reasonable suggestion differently to all the previous times the same reasonable suggestion was already reasonably answered.

Please update to an LE13 'Generic' (not Generic-Legacy) nightly and see if that works better?

DVB support in the 3.14 vendor kernel generally requires an image that targets a specific box/device. There are quite a few different tuner/demod component combinations in circulation and device-tree describes most (but not all) of the required hardware variables used in drivers, so the individual drivers for a particular manufacturer are hacked to compile a working monolithic dvb-frontend that only works for that box. afl1 made a start on abstracting the missing device-tree bits to untangle code mess, but he went radio-silent one weekend (and has never been heard of since) so the effort stalled and nobody else ever picked up the challenge. The 4.9 kernel codebase is largely a forward-port of the same bad code used in 3.14 (which is a forward-port from 3.10) but newer hardware from that era tends to copy the Amlogic reference designs closely so less variation of tuner/demod combinations and a small amount of code improvement results in a single (still hacked-together) image working for a wider range of no-name boxes.

TL/DR; You likely need the original kernel sources for the box(es) to make a working image because the device-tree files on their own only contain part of the detail needed to make the hardware (as implemented in that box) work properly.

rdorsch slideshows are probably using shaders which might have a connection to e.g. the mesa version, but in general it sounds like something that needs to be investigated from the Kodi side; especially with Piers technically still in a pre-alpha state. It's worth seeing if the feature works on another distro or platform.

Attach a keyboard and press 'i' when this is playing and it should go away, and then only reappear (briefly) when the track changes.

It sounds like the core OS boots and runs fine but something fails/faults with Xorg so the Kodi home screen doesn't show and then Kodi is restarted (ad infinitum).

If you have an AMD GPU the first thing I would do is reinstall with the Generic (not Generic-Legacy) image. I would also use a current LE13 nightly to have the latest drivers (not that this guarantees anything). If the Generic image does something similar, e.g. the boot splash shows but the Kodi home screen then doesn't overwrite it, you can access the 'Logfiles' Samba share over Ethernet and either upload the zip file or (better) pastebin the system and kodi logs so we can maybe see what went wrong.

Quote from vbs

isn't what you describe (ignore dynamic metadata and use the static metadata) already happening right now?

Yup. Current LE images are using ffmpeg 7.1 and 8.1 is queued up for LE13 nightlies. What you described as some future thing we need to add .. is something we've been doing for ages already.

The upstream Motorcomm driver is enabled in RK images but code shows "Motorcomm 8511/8521/8531/8531S/8821 PHY driver." so I would assume it doesn't support YT6801 and something downstream will be needed. The challenge here is that a) downstream drivers are normally written for old Android kernels and are garbage quality, b) in the last year LE finally exorcised the last out-of-tree vendor driver from our codebase, and that effort took a decade, so we aren't going to enthusiastically add/allow more of them back into the codebase again. I'll entertain the idea of backporting submissions to kernel mailing lists that show promise of being merged (and thus patches can be dropped in a future kernel bump) but out of tree things are a firm no these days.

There's plentiful information on how to build custom images in the wiki. Learn how to search for driver names using "git grep" to discover references to them in packages and config files within the codebase.

Quote from vbs

Will this make DolbyVision support possible in LE and is it planned to support that?

The current level of support allows ffmpeg to detect the presence of DV content and depending on the DV variant, do things like ignore dynamic metadata thus allowing playback to use the static core data and still render something. This then allows OpenGL using systems to tonemap ouptut and show something that resembles SDR. There is no support for variants that do not contain static core data, and Kodi/LE does not currently attempt tonemapping on OpenGLES hardware (90% of our userbase).

I do not expect to see "true" DV support anytime soon. There is one known 'open-source' implementation that aims to support FEL7 but this depends upon the Amlogic vendor kernel and Amlogic hardware that supports DV, and although this is now mostly working and the implementation is 'open' since it does not depend upon closed-source dolby licensed binaries; the developers have had to implement portions as a closed-source ARM secureworld app to avoid the implementation being inspected by e.g. an army of Dolby lawyers looking to protect their intellectual property. There is a desire to share information on the implementation thus leading to better public open-source support, but both the sharer and receiver(s) of shared information need to carefully consider how this is done to avoid the strong probability of the sharing act attracting legal problems.

Yay for users backing closed-source formats!

Have you read https://kodi.wiki/view/Playlists ?

2025-06-26 08:44:18.884 T:1120    debug <general>: CDRMUtils::FindConnector - failed to find connected connector
2025-06-26 08:44:18.884 T:1120    error <general>: CWinSystemGbm::InitWindowSystem - failed to initialize Atomic DRM

The 'van' log continues to show ^ no HDMI device attached. The 'monitor' log is normal in comparison.

If you remove the SD card and power on the board the firmware shows a bios-like screen with information and along the bottom of the screen there is basic detection of EDID data from a connected display device. I'd guess you will see "EDID: none" which confirms there is no display attached (or detected). LE can use either HDMI port for video/audio but CEC only maps to the HDMI port nearest the power socket so you'll see this described as preferred in many forum posts.

The other trick to try, is running "getedid create" when attached to the monitor. This captures the monitor's EDID data to file and configures the kernel DRM layer to read EDID data from file instead of auto-detecting it from cables. This will guarantee the kernel 'sees' a connected device (the monitor) and outputs appropriate to that device. As long as the van HDMI display can handle that input, it might force things to work. If the van display does not like that input, you either need to fix things so HDMI handshaking and auto-detect works, or you need to run "edid delete" to remove the existing capture, then rinse/repeat the process with another HDMI device until you chance upon one that does work. Note that HDMI audio properties are also defined by EDID data, so unless you are using analogue output (or a DAC board) on the RPi the HDMI device you capture EDID data from can be important.

LE10 uses 'arm' userspace whereas LE12 and newer use 'aarch64' userspace. The ChromeOS images are thus different in size as they are different images targetting different ChromeOS devices and architectures. As the issues with inputstream.helper seem to be resolve I would simply remove /storage/.kodi/cdm and allow it to install the correct widevine lib in the correct place.

NB: having the correct widevine lib installed does not guarantee the Netflix add-on works. It seems some things related to the (no longer recent) DRM changes on the site still aren't understood and that impacts usage. That's a topic for the support thread in the Kodi forum and/or GitHub issue though, not here.

The debug log won't show anything useful because the issue exists within the Chrome browser, which doesn't generate "log" data when it renders pages in the same way Kodi logs playing media/streams.

beyondthegrave RAM size is intentionally capped as some Rockchip drivers assume 32-bit memory ranges and behave badly with ranges above 4GB. HDR is not implemented yet, and I don't expect that to change for a while yet.

2025-06-26 08:44:18.950 T:1123    debug <general>: CDRMUtils::OpenDrm - opened render node: /dev/dri/renderD128
2025-06-26 08:44:18.950 T:1123    debug <general>: COffScreenModeSetting::InitDrm - initialized offscreen DRM
2025-06-26 08:44:19.064 T:1123    debug <general>: CWinSystemGbm::InitWindowSystem - initialized DRM
2025-06-26 08:44:19.064 T:1123     info <general>: Found resolution 1280x720 with 1280x720 @ 50.000000 Hz

The "initialized offscreen DRM" message means the kernel did not detect a DRM display device and Kodi started in offscreen mode and the fake resolution for offscreen mode just happens to be 720p.

If the board is connected to the van's screen via HDMI, I would be investigating cables and adapters first.