Posts by chewitt

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.

Have a read: https://wiki.libreelec.tv/configuration/edid#raspberry-pi

I'm attempting to guess/fix the GXLX audio problem in the posts above. Nothing that needs you to update all the time.

If the IPTV service is the typical pirate variety that users show up with and try to hide by only sharing little log snippets due to forum rules; a) you're probably getting a service level appropriate to what you pay for, b) we don't care. If it's one of the rare occasions where this is a real legitimate IPTV service; please share a full debug log.

LE tracks the upstream Pi repo's closely so if using any nightly images we're probably already on the latest update for kernel and firmware. You can update the boot eeprom with "rpi-eeprom-update -a" but there's nothing else (USB firmware is an RPi4 only thing).

  #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.

dmladenov I've undone my last change and implemented the regmap poke from Hexdump0815's patch exactly. Please update again using the latest https://chewitt.libreelec.tv/testing/LibreE…h64-11.80.0.tar and see if that works?

[    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?

Nothing changed. You can re-read post #2.

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.

The film is H264 or HEVC codec?

I'd suggest updating to a current LE12 nightly to see if newer kernel/drivers (everything) has any impact?

Are you using the Odroid HiFi shield or something else?

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?

LE10 > LE11 is a supported direct update. Only LE 9 > LE10 was blocked due to the Python 2 > 3 change.

Share logs. Our ESP is pretty bad.

I pushed a minor tweak to https://chewitt.libreelec.tv/testing/LibreE…h64-11.80.0.tar so you can update and share dmesg again (please) but the previous log you shared shows the audio card as detected in the kernel and Kodi and once you ignore all the stalker.pvr noise in the log; the stream you played shows normal 2.0 alsa audio output. So from logs all looks normal

The "special://" URI prefix maps to the root of where Kodi writes data, e.g. /storage/.kodi .. but that's a Kodi internal thing so firstly OpenVPN doesn't understand it, and second askpass doesn't accept URIs as input only paths.

If an absolute /path/to/the/file isn't working it might be relative, e.g. if JimH.ovpn and user.txt are in the same folder, only add the filename alongside 'askpass' and don't add the path.

If that's not it you probably need to look into (or share) the OpenVPN log. I've never used that add-on but I'd guess it generates a log somewhere and that might have more info.

LE11 "Generic" now uses GBM graphics not Xorg so there is no nVidia support. You need to update use the "Generic Legacy" image which does use Xorg and has nVidia support.