Posts by chewitt

    Code
    mkdir -p /storage/.config/firmware/brcm
    wget http://ix.io/4tpc -O /storage/.config/firmware/brcm/brcmfmac4330-sdio.oranth,tanix-tx6.txt
    reboot

    ^ see if that nvram config works better. Run "pastekodi" and "ifconfig | paste" after boot and share the URLs. Also ensure the correct wireless regulatory domain has been configured in LE settings.

    Kodi hasn't been niche for 20 years and while LE is smaller, we've always sought to keep the distro simple and one of the ways that's done it avoiding niche things that few people use. To quote Spock .. "the needs of the many outweigh the needs of the few" :)

    I wouldn't guarantee that the subreddit has official team members moderating it. Kodi forums are the correct place to make and discuss feature requests but you'll need to find someone who cares to code the feature.

    The "error" messages related to brcmfmac are harmless since the driver falls back to the generic filenames automatically and no device has the clm_blob file available (and it's not essential. All looks good to me; so there should be a wlan0 device in the OS and you should be able to configure a WiFi connection. If not, share "journalctl | paste" after attempting to configure a connection.

    Seeing as both the projects mentioned above do have the source code available as open source, would it be possible to include a feature built-in to Kodi for this?

    Kodi is open-source to technically everything is always possible, but since most projectors have in-built keystone correction capabilities adding a software correction feature is a niche use-case; and the perpetual challenge with niche use-cases and open-source is finding that one other person with the coding skills and motivation to implement and then maintain support for the feature.

    It's not something LE would do .. in part because it would need to be done in Kodi; we only package Kodi into a convenient distro image.

    The boot log shows the kernel probed SDIO and loaded firmware this time so there should be a "wlan0" device listed if you run "ifconfig" but there are ieee80211 errors. See if "iwconfig wlan0 power off" stops them? .. and also try to create a WiFi connection.

    Code
    cd /storage/.update
    wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-11.0.2.tar
    reboot

    ^ please update to that image and share the boot log again. The WiFi card appears to be the newer BCM43752 chip (as that's what the BT driver loaded firmware for) but it's odd the kernel doesn't show any attempt to probe SDIO. I can ask the Minix devs for the Android dts and schematics to look at.

    Casting and streaming media "to" other devices gets complicated. It's easier to simply setup a central repository of media and then have the respective client devices independently connect and play media from it. In a home this would be a NAS device that can serve files over SMB, and with native Kodi apps for the different client device OS in use. The NAS can connects to a WiFi router, and if possible has an Ethernet connection to the Living Room player device (RPi4) as nothing sucks more than shitty WiFi killing the movie mood. Firesticks can also run Kodi natively, accessing the same content over SMB. If the NAS has options for Plex or Jellyfin you also have other options for native player apps with different features, e.g. Plex can serve content on-the-fly at reduced resolution which can be useful for WiFi connected clients that may have lower bandwidth, and kids don't care whether something is 4K or HD .. they care they're watching a movie with cousins.

    As the NAS device is running in an environment with less stable power arrangements I'd use SSDs for storage instead of spinning drives. It won't prevent filesystems getting corrupted by will avoid physical drive damage from sudden power loss. Using a NAS and SSDs is more expensive than trying to frankenstein something with Raspberry Pi's and USB drives, but any trailer that size and with 3x TVs isn't exactly downmarket camping so you can probably afford it :)

    Kodi is pre-configured for 1080p max as RPi4 (and all the other ARM boards/boxes we support) don't have the CPU grunt + I/O performance + memory bandwidth for handling 4K artwork. If you really must have 4K GUI .. you'll need to switch to a higher-end Intel device with fast RAM and an SSD or NVMe drive. And then you'll discover that most TVs do a better job of scaling 1080p art to 4K than Kodi does.

    Have a read: https://wiki.libreelec.tv/configuration/4k-hdr

    Quote

    2023-04-30 16:23:11.551 T:843 error <general>: CVideoLayerBridgeDRMPRIME::Map - failed to add fb 0, ret = -22
    2023-04-30 16:23:11.556 T:843 debug <general>: CDRMUtils::DrmFbDestroyCallback - removing framebuffer: 44

    ^ those are shown while playing the first file, but I have no clue what the cause might be. I would suggest that you enable "adjust refresh" with 1080@60/59.94/50/24/23.976 modes whitelisted and "mode doubling" enabled, but I'm not sure that will alter the experience. You need to have DRMPRIME decoding enabled (it should be by default).

    You can also try updating to https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.2.tar which uses a newer kernel and marginally different patches. Again, I have low expectations of anything changing .. but you never know /shrug

    phemmer Ignoring the obvious I/O errors, the one thing that stands out to me is this:

    [ 1.557543] meson_uart c11084c0.serial: Failed to create device link (0x180) with wifi32k

    Most of the errors are I/O and look like a dying SD card or perhaps bad PSU that causes instability issues for the (known to be problematically sensitive) MMC devices: SD/eMMC/SDIO. The failure of the wifi32k device to probe right means WiFi (SDIO) will not work, but oddly the other UART based device, BT, appears to proble. Most odd. Another possible cause is the MMC clock speed being too high, but it's only 100MHz (default in the upstream kernel is 50MHz) and it's been stable at that rate with other devices (stats show other U9-H users) so I don't think that's the reason. If the device has been booting CE or Android fine that would generally rule out PSU issues; they would likely show up in other OS too.

    Please put this on a new/different SD card https://chewitt.libreelec.tv/testing/LibreE….0.2-box.img.gz and see if you can grab the boot log again. I'm not seriously expecting anything to be different but it has some additional patches and a newer kernel than the official release so you never know /shrug