Posts by chewitt

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.

If the sources are in a git tree edit the file with the changes then either commit the changes and run "git format-patch HEAD~1" or without committing do "git diff > linux-force-yuv.patch" .. either way gets you a diff patch with the correct paths.

Quote from gillesb2002

How do I know which one to choose

You need to do personal research or pull containers and try them until you find one that suits your needs. I can't advise in any more detail because I don't (and have never) run Kodi in a container; I have a simple lightweight OS that does what I need.

Quote from Tweety

Are the modules for Wifi/BT/Lan generally included?

Everything here is included https://github.com/LibreELEC/brcmfmac_sdio-firmware - and if whatever AP6256 is? is not there, it can be added. You can also follow https://wiki.libreelec.tv/how-to/add-firmware to fix missing firmware yourself while waiting for the embedded firmware to be updated (after you point us to the source).

NB: Broadcom drivers are enabled. Realtek LAN modules are enabled (once in a while some vendor comes up with some other weird Ethernet arrangement, but that's rare).

The OE patch added a driver for Spinelplus IR receivers, but it requires a bunch of USB ID's to be patched into common kernel files that are frequently updated, and because the original author never bothered to upstream the driver, the downstream patch needed constant rebasing against kernel changes. This task quickly becomes a problem chore, so the patch was eventually dropped.

In the absence of a proper kernel driver you can fall back to using lirc, which still exists in LE but (IIRC) lircd is no longer started unless /storage/.config/lircd.conf exists. Step 2 and Step 4 from the article you linked should still be valid.

I didn't make any serious attempt to investigate PT audio, and even when I do there's a low probability of me being able to spot what's missing. At least normal PCM output works correctly now.

This is forum for Linux not a forum for Android ROMs. Use 4pda or similar that cares for Android things.

Output is HDMI *or* Composite, never both. Composite refresh-rates are defined in common kernel code (not Amlogic driver code) and implement the broadcast specs for NTSC or PAL, neither of which use 59.94 output.

Kodi does not support dynamic reconfiguration of itself each time you switch display device (although it is mildly tolerant of changes within the same display techology, e.g. one HDMI device to another HDMI device). So install the device to the screen that you intend to use and the leave it in a working state. If you keep switching, expect it to keep breaking.

If you connect Ethernet the default route will switch to Ethernet. It's possible to change ConnMan behaviours by copying the config file in /etc/connman/main.conf to /storate/.config/connman_main.conf and changing PreferredTechnologies = ethernet,wifi to PreferredTechnologies = wifi,ethernet then connecting Ethernet won't steal the default route.

I've no idea about analogue audio output. The p201 device-tree file does not implement support for analogue audio, but that's not unusual as on most GXBB (S905) designs the DAC is hardwired (always on) so there's nothing to enable or control from software other than the global (master) volume level. If your box is different and has a controllable DAC chip it will require the driver to be enabled in the kernel config and the DAC chip to be described in device-tree; and then you'll need to script post-boot changes to the default mixer settings (which are configured on boot for HDMI output) to switch i2s output to the DAC chip.

NB: If you want something cheap that better supports Composite output, my suggestion would be to use an RPi board. Composite on Amlogic hardware isn't something that's ever been tested by me (as I have nothing that accepts Composite input) so our images are oriented towards HDMI usage and you're probably going to fight the OS at every turn.

LE does not implement boot menu's so no idea what you're talking about there.

No idea. I've always edited /storage/.kodi/userdata/sources.xml over SSH to type the info in with a keyboard as it's much easier than the so-called "easy" method of browsing the network and typing passwords using a remote control.

Our crystal ball isn't working today so you might need to demonstrate the problem and share logs.

Quote from Tweety

If I understand it correctly, than these files may differ

There is no 'may differ' the kernels are different so the device-tree descriptions of hardware are different. There is enough common heritage that you can probably get something to boot using a device-tree file from the latest downstream Rockchip kernel (Linux 6.6 IIRC) but differences mean specific things are not described correctly and that results in those things either not existing or not working correctly.

If you edit extlinux.conf on the SD card and change FDTDIR / to FDT /rockchip/rk3588s-orangepi-5.dtb u-boot will not autoselect the dtb file to use and will boot that specific device-tree file. Experiment with the Opi 5 and 5b files (which are also RK3588S) and see if either of them (or perhaps other RK3588S boards) work better. Things like hardware decode should be enabled for every upstream board. Things like Networking might be wired up differently on different boards.