Posts by chewitt

Nope.

The "use an external grabber" does mean some extra $$, but it's also the method that works the same on any past/present/future device; freeing you to use whatever works for your needs and not worry about it again.

Have a read of this: https://wiki.libreelec.tv/development/git-tutorial

In short, you need to create a diff patch that patches the kernel sources either modifies the x96-max dts file or (better) adds a new dts file for your box. Clone Linux kernel sources from https://github.com/chewitt/linux/commits/amlogic-6.1.y then create a new branch and make and then commit changes. You can then generate the diff patches from the commits (git format-patch ..) and copy them into the LE buildsystem at projects/Amlogic/devices/AMLGX/patches/linux/ then rebuild the image so the patches are applied to kernel sources and included in the built kernel. If you modify the kernel build folder direct; a) respinning the image will not pickup the changes, b) if you force the kernel package to be rebuilt this will remove the build folder and unpack it again from sources overwriting your changes.

The suspend/wake code is contained in the bl301.bin file that forms part of the early boot firmware chain; and even though we are using upstream u-boot, we are (or should be) using the same bl301 code that shipped with the original boxes, as I extracted the FIP sources from the vendor u-boot sources WeTek shared with me. If that's not the case, I don't personally have the skillset to investigate the problem much further (and don't have time or interest for learning new tricks currently either) .. so unfortunately, it is what it is

Seeking in HEVC media has flaws and some hangs are inevitable (as you found, stop and restart playback generally works). I can't explain the source changing issue, but I don't see problems with source changes on any of the boards I test with and my own receiver, and it's not something other users are reporting against AMLGX images.

Someone is rewriting HEVC support, but until I see code to test I can't say whether that's a solution, and there's no timeline.

Quote from therealwolve

Why don't you just let the community do the "hard" task and let moderate the forum? Like it's kind of standard nowadays so that users just flag/report content and it will be invisible until a mod approves/removes it?

That way the mods should have much less work and users might be happier because their legit posts are actually visible and not in limbo for hours or days because only 1(?) mod actually does this job.

Relying on users to flag spam doesn't work because when you present a shitty task to a large audience everyone hopes or assumes someone else will do it, with the result that nobody does it, except for the staff/mod users (who are already doing it, and the people doing initial post approvals and the main responders to around 2/3 of the threads in the forum anyway). So it's not really any more or less work for staff, and it's a highly effective spam block. TL/DR; It works, and despite the occasional complaint (which like busses, come along in threes) it's not going to change.

&ethmac {
    status = "okay";
    phy-handle = <&internal_ephy>;
    phy-mode = "rmii";
};

SEI510 uses the internal Ethernet PHY embedded in the SoC itself so as long as that's present in device-tree Ethernet works. The X96-Max dtb uses external PHY which requires different content and the correct compatibles to work. The SEI510 has special audio config though, which will not align to the config used with most TV boxes.

For WiFi, the SDIO bus supports discovery and probing by the kernel so as long as the bus is enabled (and is most device-tree files it is) the chip can be seen and matched to a kernel driver and used. I've added the RTL8189ES/FS drivers into my private LE sources for a while so the needed driver is present in the image. Those vendor drivers are deliberately not present in the main LE releases, and that's not going to change. You can find the packages here: https://github.com/chewitt/LibreELEC.tv/commits/amlogic

It should be fairly simple to create a device-tree for the box. Start with the X96-Max and just change the Ethernet config.

Stick with the q200 dtb if that works for Ethernet. Now put Kodi into debug mode and run "pastekodi" after demonstrating a video that doesn't work right and share the URL generated.

Some progress for v/next: https://github.com/LibreELEC/LibreELEC.tv/pull/7967

To see whether this is an issue with the settings add-on or somewhere lower in the BT stack, SSH into the device and connect/pair the device using "bluetoothctl" instead the LE settings add-on. If that works; the issue is in the add-on, but the pairing/connect should be persistent now (workaround). If it still fails, the issue is likely lower level and the first step would be updating to (or testing with) an LE12 nightly where newer code/drivers are being used.

You probably need to self-build, so these would be suggested reading:

https://wiki.libreelec.tv/development/build-basics

https://wiki.libreelec.tv/development/build-commands/build-addons

"You can please some of the people some of the time"

You're probably better off asking the Q in the Kodi forums, since DLNA capabilities are Kodi features and not really specific to LE.

Kodi caches versioned addon installer zip packages in /storage/.kodi/addons/packages so if you (re)install a package which has already been downloaded and is present in the cache it will be installed using the cached package and will not be (re)downloaded. Kodi also stores add-on settings under /storage/.kodi/userdata/addon_data so when you delete something and it asks you about deleting data on disk; that's what it refers to. If you don't delete the data on disk you can delete the add-on (will not be present in /storage/.kodi/addons) but if you later reinstall the add-on the previous add-on settings will be reused. Since DVB client add-ons interact with DVB server/source apps; some config may be persisted upstream too, e.g. channel layouts and EPG settings.

Have a read here: https://wiki.libreelec.tv/configuration/…troubleshooting

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

^ Adding this to kernel boot params (the APPEND line in syslinux.cfg) forces the video output to the HDMI-A-1 adapter. Set this if wanting to use HDMI and not the internal screen (LVDS) or change the adapter details to suit the second HDMI device and it will be used, else the kernel will detect/use the first device probed (on a laptop, normally the LVDS connection). You can also use content like "video=HDMI-A-1:d" to disable the HDMI-A-1 device (allowing another to be discovered) .. whichever works is good. There is no F7 style hotkey to swap outputs once Kodi has started.

Run "dmesg | paste" over SSH when booted from the Q200 and Q201 device-tree files and share the URL generated.

I'm in the UK for a while, so will see if I can find a second-hand U9-H for testing .. no promises.