Posts by chewitt

https://wiki.libreelec.tv/configuration/edid has instructions on configuring an edid.bin file so Kodi sees the TV as always connected. The wiki needs updating to reflect that the Intel instructions apply to all devices using the kernel DRM architecture; including Amlogic (and Allwinner, Rockchip) boards.

https://chewitt.libreelec.tv/edid.bin was dumped from older (2012-ish?) Samsung 8-series TV, and contains 23.976/24/25/29.97/30/50/59.94/60 modes. You might not be able to use all (or any) of them, but it might work and you can disable the ones that don't in the whitelist.

https://wiki.libreelec.tv/configuration/…ration-advanced has instructions (also needing update) on capturing and creating a custom IR config. The bit that needs updating is that the config file format has changed to "toml" .. but if you look at the wiki instructions and compare to the toml files in /usr/lib/udev/rc_keymaps/ the new format is pretty simple to crib.

Kodi only reads mode data once at startup so swaping cables after boot will not change anything. And if the 4K 50/60 modes configured in the mode whitelist are not available (due to 1.4 cables) they will be silently dropped; requiring you to edit the list and reinstate them if you reboot with higher spec 2.0 cables attached again. NB: Lots of users think they have high-speed cables and will swear on their mothers life that their cables are not the issue; but issues often magically go away when a new certified cable is purchased

DV files won't play right even if the projector does support HDR. DV media is not supported.

video=HDMI-A-1:1920x1080M@60

^ remove the current video= string and use that. What happens?

sky42 shares images that have all the RAID modules/tools and encrypted disk stuff included. Last time I looked there were ~20 active users of those images and it's been fairly consistent around that number for a few years; so I think we're justified in continuing to release without features that aren't in general demand.

You can enable "adjust refresh" in Kodi player settings, but the system will need to have a native 23.976 mode or you'll need to use an edid.bin file to fake a connected TV with more modes. The old method you found is not possible in the modern kernel used now.

Please run "pastekodi" and "modetest | paste" and share the URLs so we can see what modes and timings exist.

Quote from aqf23

I’ve done a search and found out that this is a thing with LE, but I’ve never experienced this with Kodi before. Is this a known issue?

I've never seen issues (or similar reports) with H264, so

Is the box connected via Ethernet or WiFi? .. some wireless routers isolate devices on the wireless network so e.g. WLAN connected iPad will not be able to reach WLAN connected LE device. Connecting the box to Ethernet would fix that. Or it might be the app having an issue with the SSH certificate algorithm being used (although unlikely I think).

Pls create an SD from https://chewitt.libreelec.tv/testing/LibreE….0.2-box.img.gz and set meson-gxl-s905x-nexbox-a95x.dtb in uEnv.ini. I doubt it will help the SSH issue but hopefully HDMI audio and the IR remote should work out-of-box now? If you're able to access the box via SSH please run "pastekodi" and share the log file URL. The dtb could use some other cleanup/changes but one step at a time.

Apr 06 06:12:00.956410 LibreELEC xorg-launch[615]: ================ WARNING WARNING WARNING WARNING ================
Apr 06 06:12:00.956410 LibreELEC xorg-launch[615]: This server has a video driver ABI version of 25.2 that this
Apr 06 06:12:00.956410 LibreELEC xorg-launch[615]: driver does not officially support.  Please check
Apr 06 06:12:00.956410 LibreELEC xorg-launch[615]: http://www.nvidia.com/ for driver updates or downgrade to an X
Apr 06 06:12:00.956410 LibreELEC xorg-launch[615]: server with a supported driver ABI.
Apr 06 06:12:00.956410 LibreELEC xorg-launch[615]: =================================================================
Apr 06 06:12:00.956410 LibreELEC xorg-launch[615]: (WW) NVIDIA: The driver will continue to load, but may behave strangely.
Apr 06 06:12:00.956410 LibreELEC xorg-launch[615]: (WW) NVIDIA: This driver was compiled against the X.Org server SDK from commit e6ef2b12404dfec7f23592a3524d2a63d9d25802 and may not be compatible with the final version of this SDK.

^ this reads like we bumped Xorg in LE11 to a version higher than the nVidia legacy driver supports. As a result there is no OpenGL and Kodi cannot start. And if I re-read the LE10 log now it appears to be running but also prints an swrast error (not sure why it would be trying to uset that though). GeForce 8200 is an ancient card now (2008) so I'm wondering if the current legacy drivers go back far enough?

I'm not sure what the issue is here, but ping heitbaum  CvH for awareness

The normal instruction would be to install the autoexec service add-on. You also need to ensure that the autoexec.py script works. If it doesn't perhaps the wrong commands are used? .. which should be visible in a Kodi debug log.

I'm looking in the LE(11) repo on my daily-driver RPi4 box and I can see pvr.filmon client listed and published.

Quote from miltof

Should I always use nexbox a95x as hardware now ?

Yes please. It's useful to have a known reference that the dtb works. If you see any issues, we can track them and (hopefully) fix them.

NB: Does the box have an IR remote? If yes, do you have a working keymap for it?

It's something to ask Kodi devs via their forums. Their feeds are nothing to do with LE.

Please update to LE11 and redo. I explicitly want to see the output from kmsprint which is included in the pastekodi output in LE11.

One more change: https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.2.tar .. the vendor kernel runs the SDIO module at 50MHz but let's see if it's happy to run at 100MHz? .. If it's still connecting please try scp'ing some large files to/from the box to prove the mmc is stable at the higher speed. If it's not I can down-clock back to 50MHz again.

On the negative: Realtek maintains a driver fork for each chipset variant they shipped despite the differences between variants in the same family often being very minor, and they breed new variants like rabbits so there are probably 30+ drivers in circulation. Realtek only releases their drivers to their paying-for-support customers (end-users are not their customers) so end-users have to rely on board/device vendors sharing them; over time things generally leak to GitHub but it results in 500+ repos with slightly different versions of the same "posted once and never updated again" driver being available to confuse people. There is a large amount of common boilerplate/duplicated code in each vendor driver, and while the vendor drivers generally work okay the overall code quality is low as the drivers have never been subjected to any serious peer review during development. Frequent minor changes to upstream kernel frameworks frequently result in all the drivers breaking and needing to be patched so the drivers are a pain in the arse to maintain over time. The fact the drivers are released with a GPL license is good, but that's about the only good thing to report. Distro maintainers loathe these drivers.

On the positive: Realtek have finally embraced upstreaming their drivers and are now contributing-to and maintaining a single driver per chip family. However their primary interest is in PCI/USB drivers and the SDIO ones are often forgotten, and this is a relatively recent development so they are only investing time/effort into the latest chipsets that nobody is really using yet, not the older chipsets that are endemic. They do comment on patches for older chipsets/drivers when asked, but community developers are the primary source of development for the older chipsets. So future support looks better, but support for everything shipped in the last decade is still a bit sucky.

I'm not sure why the Realtek driver is flagged as staging in Debian (something for Debian maintainers to explain) but I am 100% confident this is the legacy Realtek vendor driver and not the upstream kernel staging driver.

Please do "pastekodi" over SSH and share the URL so we can see what's detected/connected.

Have you enabled "disable password auth" in SSH options? - this will not stop the box for prompting for a password if you connect, but it will stop passwords from ever being accepted.

Are you using the original remote for the box? .. If yes, can you share the files? - I can see the issue with audio; the required sound-card nodes are missing from meson-gxl-s905-nexbox-a95x.dts. This is simple to fix and I would like to add audio/remote and have you test.