Posts by chewitt

Kodi generally aims to ship something before DevCon (so we can talk about it then) and in recent years this seems to be happening in March/April so the release is most likely to happen in Feb .. but no guarantees

The image in post #1 is 100% the mesa issue resolved in nightlies so unless you've mixed up SD cards and are still booting the 12.0.1 image and not the LE12 or LE13 nightly, there's no real explanation. The nightlies work for other users with boards using the newer chip stepping.

You can add "ssh" to boot params in the cmdline.txt file on the SD card and this will force the SSH daemon to start so you can login to poke around and generate logs. You can also access the "Logfiles" SMB share over the network to generate a zip file in the share with all the logs, but if you are still seeing the same image as shown in post #1 there probably won't be anything useful as systems are up/working okay - only the mesa version is missing support for the newer chip stepping and doesn't render things correctly.

I'd recommend (re)setting the desktop resolution to 1080@60. This is the max resolution for current skins and forcing things to 4K desktop just makes the UI run slower. Configure 4K modes in the mode whitelist for playback only.

"If it works, don't fix it" .. so if you're happy with the RPi4's, an RPi5 is the natural choice. Being a mean parent I'd bag the RPi5 for myself and pass down an RPi4 to the kid

Show the output of all the commands, in sequence, or copy/paste to pastebin.com or similar.

Yup, looks like the device is present but there are no paritions/filesystems - You need to create one. The commands I shared in the second code-block above should fix that.

RPi5:~ # ls -l /dev/nvme*
crw-------    1 root     root      243,   0 Dec  6 03:29 /dev/nvme0
brw-rw----    1 root     disk      259,   0 Dec  6 03:29 /dev/nvme0n1
brw-rw----    1 root     disk      259,   1 Dec  6 03:29 /dev/nvme0n1p1
brw-rw----    1 root     disk      259,   2 Dec  6 03:29 /dev/nvme0n1p2

If you do ^ that, do you see at least /dev/nvme0 listed? - I'm not really seeing any errors but there's no mention of any partitions being checked or mounted. The probable and logical explanation for that would simply be that none exist on the drive and you need to create one, e.g. (not 100% sure of the commands here, am working from memory):

parted -s /dev/nvme0n1 mklabel gpt
parted -s /dev/nvme0n1 mkpart primary ext4 40s 100%
parted -s /dev/nvme0n1 name 1 'MEDIA'
mkfs.ext4 -L "MEDIA" /dev/nvme0n1p1
fsck.ext4 -y /dev/nvme0n1p1

If that's not the issue I'm unsure what the actual issue is, so hard to advise.

Monitors with different display properties might require full-range, but normal TV's should be fine with limited range, so no need to fiddle with anything. Nothing to change for HDR content either.

I was being a little lazy, but if you follow the instructions the log pasted includes "dmesg" content, which is the info needed. Instead you shared a Kodi debug log directly which is thus missing all the useful info.

Using "getedid create" will capture the 4K modes, but I think the AVR will fail to pass a 4K HDMI signal even if you try to force it that way - this stuff should "just work" without forcing. I think you need to experiment with connecting the AVR to other HDMI ports on the TV and/or connecting the RPi5 to other ports on the AVR. It is common for HDMI ports to have different capabilities and perhaps one side is set for "PC" mode or such? - the list of resolutions reminds me of standard vesa modes for that kind of use.

Quote from JohnWayne111

I delete the edid via "getedid delete" and reboot the PI. Nothing has changed.

Nothing should change. The RPi5 should continue using 1080p desktop resolution; this is the default and best setting. You should now be able to go into Kodi video settings and add 3840x2160 resolutions to the mode whitelist so that Kodi can use them for 4K playback. See https://wiki.libreelec.tv/configuration/4k-hdr for more info.

I would remove the getedid stuff unless you plan to boot the RPi5 with the AVR disconnected, it's not really needed.

LE12 or LE13 nightlies resolve the issue - both are stable for regular use.

LE defaults the Samba server credential to libreelec/libreelec and this can be changed to whatever you like in LE settings.

Any difference between cold boot and warm (re)boot?

echo "sleep 10" > /storage/.config/autostart.sh

See if that ^ works around the issue? .. it will delay Kodi startup for 10 seconds, which should allow kernel drivers to finish loading in the background.

dnmnhat the SSH daemon is not running because it cannot write keys to /storage/.cache .. but the reason it cannot write them is not clear from the log as it does not show the early stages of boot, only later stages. This is probably due to the log rotating; which is not helpful in this scenario but probably indicates something failing repeatedly causing the log to fill/overflow and reach the log size limit. I'd guess that something is wrong with the /storage partition causing it to mount read-only. If you are booting the box from an SD card, the card probably has an issue; so find another to test with. If booting from internal storage (probably not with a mecool box) go find an SD card and boot the device that way to hopefully get a clean log and see what might be up with eMMC storage.

Create /storage/.config/firmware/mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin and WIFI_RAM_CODE_MT7961_1.bin then reboot and the files will be overlaid on /usr/lib/firmware and used instead of the embedded files.

Please try the latest firmware files from: https://git.kernel.org/pub/scm/linux/…t/tree/mediatek

If those are not working, an issue needs to be reported to kernel maintainers. If they are we can bump the embedded firmware.