Posts by chewitt

    If there's an issue it seems to be localised to your environment. I'm running a (self-built) nightly image on an RPi5 without any network issues and lots of other people run nightlies too; enough to flag-up any general networking issues. NB: The kernel changes in question will be irrelevant unless your home network is IPv6 based?

    I'd start with a clean LE13 nightly image on a spare SD card. Any different?

    The only mention of a USB drive device in the system log ^

    The "Media removed, stopped polling" makes me suspect power issues. You can add "usb_max_current_enable=1" to config.txt and see if that makes a difference. Note that RPi5 needs a decent PSU (official one is recommended).

    Have a read of this https://github.com/LibreELEC/amlogic-boot-fip/pull/27 - and please note that this forum really isn't interested in dealing with Android backup/recovery issues (not our OS, not our problem).

    Also note that LE does not support install of the OS to the internal storage and while booting LE from an SD card changes the boot process slightly it's not harmful to the Android install - modern upstream kernels cannot see/mount any of the partitions created by the vendor boot firmware due to Amlogic's proprietary partition scheme - so we're not going to mess Android up.

    NB: You can easily dump the full content of eMMC storage from inside LE using "dd" although this is a raw image and you will not be able to use it as recovery media in the event of eMMC issues as the u-boot in the dump is for eMMC boot only; magic headers are located at the wrong offset for SD/USB boot due to S905 requiring different offsets.

    On the TV you can see the detailed signal info, which shows that HDR was enabled for the HDR content.

    HDR is a much more nebulous concept than most people realise. It's not a fixed standard like "4K" and forcibly adding metadata to the HDMI signal to switch the TV into "make everything bright and show the logo" mode is simple and doesn't need to have any relationship to media being played. I wouldn't be too surprised if Windows drivers look for properties frequently associated with HDR and fake/trigger the mode change on the TV and/or blindly force output in some way. Linux is going to limit the output options based on what is possible, and while EDID suggests the TV supports HDR colourspaces (which can be seen in the debug log) that alone doesn't guarantee that HDR is possible. Again, the odd/incomplete set of resolutions listed suggests to me that something isn't right in the HDMI chain - symptoms not cause.

    Code
    Found resolution 4096x2160 with 4096x2160 @ 24.000000 Hz
    Found resolution 4096x2160 with 4096x2160 @ 23.976025 Hz
    Found resolution 3840x2160 with 3840x2160 @ 30.000000 Hz
    Found resolution 3840x2160 with 3840x2160 @ 29.970032 Hz
    Found resolution 3840x2160 with 3840x2160 @ 25.000000 Hz
    Found resolution 3840x2160 with 3840x2160 @ 24.000000 Hz
    Found resolution 3840x2160 with 3840x2160 @ 23.976025 Hz
    Found resolution 1920x1080 with 1920x1080 @ 60.000000 Hz
    Found resolution 1920x1080 with 1920x1080 @ 59.940063 Hz
    Found resolution 1920x1080 with 1920x1080 @ 50.000000 Hz

    The thing that stands out to me is ^ that's an odd collection of resolutions for a modern AVR and TV to have. I'd expect to see 1080p @ 30/29.97/25/24/23.976 not just 60/59.94/50, and the full range of 4K (4096 and 3840) resolutions not a few (but again, not all) of the < 30 ones. To me that suggests something isn't right with cables/ports (or the configuration of ports) in the HDMI chain; and I'd normally point fingers at the TV side since AVR's generally default to mirroring the upstream HDMI capabilities to the downstream HTPC device (although they too can fiddle with things).

    The curveball on modern PC boxes with DP hardware is whether an LSPCON chip is being used to generate HDMI, and if yes, what bugs the LSPCON firmware has, because they are notorious for issues - including the "but it worked in Windows" kind.