Posts by chewitt

    The other standard advice to resolve CEC issues is: turn everything off, physically unplug cables, go make a coffee/tea (add some minutes of time delay in the sequence) then reconnect cables and power it all back on again. It sounds like random juju, but it genuinely does resolve some issues for users (no guarantees for yours, but harmless and free to try).

    ^ that's the current whitelist decision tree outcome. Kodi will handle scaling 720p content to 2160p without trouble but I'd expect playing 25fps content at 30fps to result in visible glitches. It also looks like you have a 4K desktop resolution?

    This article contains general advice for better GUI and playback experience: https://wiki.libreelec.tv/configuration/4k-hdr

    I don't ever test CEC functions so it's hard for me to comment, but if it's working intermittently I'm wondering if timing impacts the problem, i.e. whether Kodi starts before something is ready. You can test/prove that by restarting Kodi with "systemctl restart kodi" over SSH. If it works on restart, it's timing. If it's still intermittent, it's something else. For device-trees you just have to experiment. Google says the box has GB Ethernet so p200 should work; p201 has internal 10/100 PHY only.

    Code
      #0 1920x1200 59.95 1920 1968 2000 2080 1200 1203 1209 1235 154000 flags: phsync, nvsync; type: preferred, driver
      #1 1600x1200 60.00 1600 1664 1856 2160 1200 1201 1204 1250 162000 flags: phsync, pvsync; type: driver
      #2 1680x1050 59.88 1680 1728 1760 1840 1050 1053 1059 1080 119000 flags: phsync, nvsync; type: driver
      #3 1280x1024 60.02 1280 1328 1440 1688 1024 1025 1028 1066 108000 flags: phsync, pvsync; type: driver
      #4 1280x960 60.00 1280 1376 1488 1800 960 961 964 1000 108000 flags: phsync, pvsync; type: driver
      #5 1024x768 60.00 1024 1048 1184 1344 768 771 777 806 65000 flags: nhsync, nvsync; type: driver
      #6 800x600 60.32 800 840 968 1056 600 601 605 628 40000 flags: phsync, pvsync; type: driver

    ^ Those are the modes EDID shows as supported on the monitor, so the "1920x1080: 60" mode Kodi is looking for is indeed not in the list and .. something behaves badly. The only place I can think of where we hardcode something about 1920x1080 is the default screen resolution to use, which is "<setting id="videoscreen.screenmode" default="true">0192001080060.00000pstd</setting>" in /storage/.kodi/userdata/guisettings.xml, so perhaps stop Kodi and edit it to be "0192001200059.95000pstd" and see if that makes any difference? .. If that does have some effect it's a little odd as Kodi should handle things more gracefully. The other way to test around that would be to connect the board to a TV that has 1920x1080 modes.

    Code
    [    3.437584] meson-drm d0100000.vpu: [drm] User-defined mode not supported: "1920x1080": 60 173106 1920 2048 2248 2576 1080 1083 1088 1120 0x20 0x6

    The Kodi log shows it starts and reaches the point where it detects the DRM devices available and then attempts to select a usable surface for rendering output to. This results in the "mode not supported" (as above) being written into the sysytem log.

    Can you run "modetest | paste" and share the URL so we can see what DRM things are available?

    Kodi support for user "profiles" isn't brilliant, but things that will make the quest easier are separating the movies into different sources. The scrapers don't differentiate on content but different users can have different sources available. You can also use the node editor add-on to create new nodes (items like 'recently added' and 'genres' are nodes) with source(s) used as node criteria making a "Kids Movies" node under Movies possible. Creating a top-level menu item requires either skin hacking or skins that allow menu items to be created. I've no idea which skins support that as I'm a committed Estuary user, but I believe some can do it.

    dmladenov some IRC chat with @hexdump0815 pointed me to https://github.com/hexdump0815/li…xlx-audio.patch which I've reworked so the magic register poke is only applied to GXLX boards: https://github.com/chewitt/linux/…a8167cd10ab6b67. It's not an upstreamable patch, but if it works I'll figure out more :)

    Please update to https://chewitt.libreelec.tv/testing/LibreE…h64-11.80.0.tar and see if audio works now?