Posts by chewitt

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.

Start with an update to current LE13 nightlies which use a newer kernel - share dmesg again.

This is what Kodi announces over mDNS:

In theory the discover module should be automagically creating an Airplay sink based on the advertised properties (S16,44100,2-ch,etc.) and nothing more than this should be needed:

context.modules = [
   {
       name = libpipewire-module-raop-discover
       args = { }
   }
]

What does the output from pactl list sinks show?

Spotted this in Google results: https://wiki.geekworm.com/NVMe_SSD_boot_…_Raspberry_Pi_5 which states "We recommend avoiding the following NVMe SSD drives which is equipped with a Phison controller due to their proven incompatibility:" .. and the Corsair MP600 is listed. However there are notes on the same page and posts in RPi forums that hint some devices are then working with after RPi firmware updates (and with updates from early 2024, which is some time ago now).

So three things to do:

• Update to a current LE13 nightly (these are stable)
• Update the RPi eeprom firmware to latest (can be done via LE settings add-on)
• See if adding dtparam=pciex1_gen=3 to /flash/config.txt helps

Do one thing at a time so you can see what made the difference, should it start working. If it doesn't, I'll be pointing fingers at the Phison controller and suspecting not-all issues are resolved.

EDIT: Also share the URL from "dmesg | paste" so we can see if there's something in the system log.

There's nothing to change on the LE side because Kodi provides a working AirPlay target that devices can stream to - You proved that with the iPad mini. Ergo, if nothing happens (or wrong things happen) when you stream from the Arch device; something is wrong with the stream that you send.

It's not an LE problem but if you want us to guess at the issue I'd start by sharing the Arch discover.conf file so we can see what sink properties are being used. Plus a Kodi debug log that might show the inbound stream details (or not, I'm guessing).

Quote

Support for 24-bit and floating-point audio at up to 384,000hz

^ read from https://kodi.wiki/view/AudioEngine .. and visible here:

xbmc/xbmc/cores/AudioEngine/Sinks/AESinkALSA.cpp at master · xbmc/xbmc

Kodi is an award-winning free and open source home theater/media center software and entertainment hub for digital media. With its beautiful interface and…

github.com

Patching that list to add a higher value would be simple, but I doubt things are that simple.

If you update to an LE13 nightly where the kernel is now on Linux 6.12, this patch (and others in the same series) is included:

[3/3] ASoC: spdif: extend supported rates to 768kHz - Patchwork

Run "pastekodi" with Kodi in debug mode again post-update.

In the older thread the "update from RPi" was a simple version bump to the MPD software used in the add-on, and that change was merged for all devices (back in 2021) and likely bumped to something more current a bunch of times since then. You can also see that we build mpd with WavPack support: https://github.com/LibreELEC/Libr…/package.mk#L91

Please run "lsusb -tvv | paste" and share the URL. This should list the USB devices and the drivers used - likely to be a generic USB audio device driver. I can then poke around in kernel code to see what max rates the driver supports (likely 384KHz).

LE 9.2.8 was released explicity to support RPi4 (Generic etc. stopped at LE 9.2.6) but "support" means the image boots/runs, it does not mean "all hardware features or RPi3 work on RPi4" and the LE 9.2.8 image will only boot on the original RPi4 hardware not newer iterations that need newer RPi firmware; although that can be fixed by copying files around. IIRC, even under LE 9.2.8 the RPi4 has never supported 3D because while many RPi4 chip features are intentionally similar/same to the RPi3, the GPU is different, and OMX etc. would need work to support it, which wasn't done for release (9.2.8 shipped the same day as RPi4 was unveiled) and then never happend once things moved to GBM/V4L2 etc. .. or something like that, I forget details now, this is some time ago!

Current LE12 or L13 nightlies will solve the issue (100% this is the newer chip needing newer mesa). LE 12.0.2 will be along soon-ish to roll up this issue.

Quote from parkay6666

"This only works for Home Assistant OS, running on Raspberry Pi. Not for Home Assistant Container."

^ simply means you cannot run the Pironman add-on container inside the HAOS container; because the Dockerfile for the add-on assumes a desktop OS is present, and the HAOS container is (like most containers) a stripped-down/minimal OS environment.

Adapting one of the existing Pi case GPIO fan-poking add-ons is probably the easiest option.

sparkplug have you added dtparam=pciex1 to /flash/config.txt?