Posts by chewitt

    NB: Team Kodi have merged a couple of changes for Windows and Android installer packaging issues and this will require a Kodi 20.4 release for Appstore/PlayStore submissions. At the curent time 20.4 has no Linux content whatsoever and thus no need for another LE release. If that changes we'll re-evaluate.

    The boot sequence is (at a high level): BIOS > Syslinux > KERNEL > SYSTEM

    If you don't see the syslinux prompt on-screen, it's a BIOS or (very old) hardware problem. If you see the syslinux prompt but no LE boot splash it probably hangs early in the KERNEL stage of boot before the splash has been rendered. If you make /flash writeable (mount -o remount,rw /flash) and remove "quiet" from kernel boot params you'll see verbose boot output on screen and messages can sometimes help to pinpoint what the problem is (take an in-focus pic with a phone and share it).

    I doubt there's too many users with c.2012 NUC hardware still in use, but in general there aren't reports of "my thing doesn't boot without a keyboard connected" and LE is intentionally designed to run on systems that don't have keyboards connected, so I'd be thinking a BIOS (might need updating) or hardware issues (PSU, coin-cell for BIOS memory, etc.) to be a more likely cause.

    Legacy images running the vendor kernel tend to support a default featureset regardless of what EDID contains (or lacks) so it doesn't necessarily exempt cables/ports from suspicion. Same p212 dtb should be fine. For WiFi, some countries need the wireless regdomain to be set before the correct channels show up (as radio properties are wrong) or you need to tell what chip is inside the box (not everything has drivers) and/or share the output from "pastekodi" with the box connected to Ethernet and share the URL generated so we can see what might be missing (firmware sometimes).

    How can I find the wireless chip my mxqpro4k uses? Is it realtek's rtl8188 or rtl8189?

    If that's the same device that you shared dmesg output from in post #73? then:

    Code
    [   11.276763] RTW: rtl8189es v5.8.9_35085.20190919

    The RTL8189ES/FS chips are all part of the same RTL8188 silicon series and basically share the same driver sources; except for a few card specific changes that require compile-time config flags to be set to 'type' the driver correctly to the card; the standard kind of "hack the existing code to work with the new chip" approach that Realtek has historically used that results in 30+ drivers to support instead of having 3-4 silicon-series drivers that use hardware detection to configure the driver appropriately. Fortuntely their new chips are doing that now, but there are no plans (as no commercial benefit to Realtek) for their staff to go back and create similar drivers for their legacy chipsets.

    Nope, with current firmware the board is either off or on; there are no suspend like states where something could remain powered up to receive CEC or USB input and wake the board. The RP1 chip does support lower power states so that might change over time with firmware updates (not soon though).

    Code
    379e093cf8d782342c380675686975ef3e039580 kodi: update to githash 06e2280
    c45329884f1c6f15223e3c00c421d929dd5d5ad6 gst-plugins-bad: update to 1.22.9
    bcaf5e7a38f4eb284867dcfcecf99202b094bbc7 gst-plugins-base: update to 1.22.9
    ba174cb6687b1bb7dc8558903fa6c024bab067c4 gstreamer: update to 1.22.9
    e8cc02175e6fdf83923804de6f98a6690249e92a mesa: update to 23.3.4

    ^ Those are the only changes between those githashes, which points the finger at the Kodi bump, which contains:

    ^ None of which really stand out as possible causes for a PVR service not starting. Hmm.

    heitbaum any ideas?

    I would run the Kodi desktop/GUI at 1080@60 not 4K@30. Use the mode whitelist to permit switching to 4K for media playback when needed but otherwise allow the TV to scale the 1080p skin and 1080p GUI to the panel 4K native resolution using it's native scaling capabilities that do a better job than Kodi and have no load impact on the HTPC device.

    NB: The only hardware that doesn't struggle with 4K desktop output is high(er) end Intel CPUs. All ARM boards run the GUI best at 1080p.

    The best recommendation we can make is to separate the DVB server functions (hardware with a kernel that supports the drivers you need and tvheadend) from the client (different hardware needing no drivers) or vote with your feet/wallet and either switch to cards from vendors who did upstream support or who package devices for "over the network" usage (SAT>IP, HDHomeRun, etc.) so there's no dependency between hardware and current kernels.

    The Kodi log isn't from an LE12 nightly image so it won't contain the EDID info that I'm looking for which is easier to read and more explicit about HDR support than tvseervice output. However, the Kodi log only shows Pulseaudio BT audio (no HDMI outputs) which is already a strong hint that EDID data is not being passed correctly on the HDMI cable. I also think "dtoverlay=vc4-kms-v3d,cma-512" is wrong as this should not be needed (it's not set by default in our RPi images). It's probably forcing HDMI output in some way, but it should not need to be forced in the first place.

    9/10 problems with HDMI on RPi4/5 boards are related to bad cables (or use of Argon cases with shitty connectors) so the first thing I'd try is a different cable.