Posts by chewitt

    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.

    It's the correct dtb to use, but it's hard to comment on what's happening without seeing the output from the debug UART connector on the board; this shows the early (u-boot) boot process that we need to manipulate to boot Linux. Note that you can't just put the SD card in and boot, you need to invoke recovery boot so that u-boot searches for (and finds) bootscripts on the SD card. Also note that you must not rename the dtb file as with legacy kernel images: https://wiki.libreelec.tv/hardware/amlogic

    Code
    cp /etc/connman/main.conf /storage/.config/connman_main.conf
    sed -i 's/PreferredTechnologies = ethernet,wifi,cellular/PreferredTechnologies = wifi,ethernet,cellular/g' /storage/.config/connman_main.conf
    reboot

    ^ beware the wrapped line in the sed command. This will tell ConnMan to prefer WiFi over Ethernet resulting in the default route to the internet being assigned to wlan0 when both eth0 and wlan0 interfaces are active.

    HDR works fine on RPi4/5 in LE11/12 and has done for ages. Put Kodi in debug mode, reboot, then run "pastekodi" from the console and share the URL so we can see what display capabilities are advertised in the TV's EDID data.

    "It depends" on how much customisation you've done as the backup function only back's up the /storage/{.cache|.config|.kodi} folders, so if you dumped other things elsewhere on /storage they will be missed.

    If you manually wget the RPi5 update file to /storage/.update and then "touch /storage/.update/.nocompat" to disable the checks we do to prevent wrong-image updates you can reboot to update the RPi4 to the RPi5 image. The first stage of update (changing files) will work. The second stage (booting) will probably fail as the RPi5 kernel will have RPi4 things missing. At that point or when the board shuts down to reboot, pull the power, move the card to the RPi5 and power on. Take a backup first and move it somewhere safe, in case somthing goes wrong.