This is perhaps worth a read: Infra-Red Remotes - LibreELEC.wiki - the initial section(s) of the page have a good description of how LE handles input devices and interaction with Kodi. It might give hints on which layer you want to inject events to.
Posts by chewitt
-
-
Random guess. Have you enabled "wait for network" in Network settings? .. LE boots fast so Kodi will often start before the network stack is up, which means the SQL DB is not accessible when Kodi attempts to connect with it. No DB = "all my movies are gone" reports from users.
-
Win10 wants to use authenticated accesss to SMB shares, so enable SMB authentication in LE settings. Working?
-
No sound from either port, or no sound from both ports at the same time?
-
What am I missing?
It looks like you are missing a legal source of media. No further support.
-
You have banned add-ons installed. No further support will be provided unless you come back with a clean system.
see: Official:Forum rules/Banned add-ons - Official Kodi Wiki
-
Index of / <= search for RPi4
-
I recently dug out the unfinished HEVC work that Maxime Jourdan started in 2019 and managed to tweak a few bits to get it to compile, and 8-bit media playback works quite well, although the decoder predates lots of the compliance work on stateful APIs so probably needs changes before things like seeking will work properly. However 10-bit media deadlocks the box immediately so there is something fundementally broken there and since the 8-bit and 10-bit code paths are firmly entangled I've had to revert the changes to have a usable image. In current state 1080p HEVC works fine on G12A and newer boxes that have the CPU grunt to software decode it, but older GXBB, GXL and GXM devices are too weak. I'm not aware of anyone working on HEVC support so I'm not expecting HEVC to improve anytime soon.
I've never seen eMMC corruption issues so cannot comment on that.
-
AFAIK these are not supported. They are not impossible to support, but we have a long-running policy of ignoring requests to add support for more Realtek devices that need out-of-tree vendor drivers that are poorly written, poorly maintained, and usually break with each new kernel release (the novelty of hunting down patches wears off over time). That's probably not the answer you're loking for, but that's the situation.
-
Create a playlist, use autostart.py (Google it with Kodi wiki) to start the playlist on Kodi start. I'm not sure if the OSD is a function of the Skin or core Kodi code, but experiment with skins; something like AEON might allow this to be disabled, or you can modify a skin to hide this function.
-
On GXBB (S905) devices BL1 checks for BL2 in sector 1 of emmc first, then sector 512 of SD and USB media. You can install mainline u-boot to the emmc device but then you cannot partition the emmc storage with MBR/GUID schemes as these store data in sector 1 breaking BL2. You can still partition emmc and run an OS from emmc but the device MUST boot from u-boot on SD card. The Amlogic u-boot works around this stupid stupid design by using a custom partition scheme; MBR with all data structures offset to avoid sector 1. This "works" but the scheme is proprietary and not supported by any normal partitioning or formatting tools. This limitation was removed in Amlogic GXL and newer SoCs which additionally check for BL2 in sector 512 on emmc allowing MBR/GUI structures to reside in sector 1 as normal with BL2 starting from sector 512.
^ TL/DR; the Hub/WP2 images in that folder are experimental and created for me to test mainline u-boot. Right now the Hub image doesn't boot (locks up) and I did not test the WP2 image (need to find the box first). The box(es) boot from emmc first allways, so you need to erase vendor u-boot from the emmc first to test these images. Then (and only then) the box will look for BL2 on the SD card and boot mainline u-boot from the SD card. To be clear. Anything you find in that folder is experimental and I provide no support. If you brick your box it's your problem not my problem to figure out how to recover things.
-
If you have Khadas images using with vendor u-boot installed you can use the "box" image on SD card to boot LE, but this probably gives funky colours needing u-boot chainload to solve. Booting CE may also mess with the u-boot environment and cause issues for the box image. The "vim3" image is for writing to emmc only (once boooted from SD card). Chat to me in the #amlogic channel in Slack, it will be easier than forum posts.
-
Форум на английском языке. Google переводчик, если нужно.
-
The MariaDB add-on installs the DB and preconfigures it for use with Kodi, so you can skip the install sections and go straight to setup:
-
As a rule we don't ban users unless they are abusive towards staff or they are spam bots, we simply refuse support and perhaps control threads to ensure others don't step in, to ensure forum rules are followed. Users (even the worst initial offenders) should always have the option to change their ways and redeem themselves with a clean/free-of-crapware system.
-
Put the matching brcmfmac43455-sdio.bin file in the same folder. You also have to reboot for the files to be overlaid on the existing ones.
-
The Beelink devs have no more/less of a clue what the issue could be as anyone else. I've looked at their boot sources (with git history) and there's no smoking gun; the sources have the same Amlogic BSP baseline that Khadas and Hardkernel use with fairly minimal hacking to account for the normal things that are different between board vendors. I've also had them ship samples to people with the skills to hopefully figure the issue out, but those folks are full-time developers and we're asking them to investigate our weird problem for $free, so we'll have to be patient until they have some time to spare. I see "Beelink doesn't care" as a wrong statement. If they didn't care they wouldn't courier $240 products to people, or provide schematics and sources to developers who haven't signed an NDA, to help customers run an OS they don't ship and don't support.
-
Dear chewitt I tried your LibreELEC-AMLGX.arm-9.80.7-beelink-s922x.img.gz image on my gt-king-pro but no luck, it did not boot. I tried to change dtb setting to pro and again didn't boot.
It's an image for emmc install (overwriting factory u-boot) not an image for SD/USB boot.
Normally I'd suggest using the "box" image to boot, then erase the emmc or use "emmctool" to write the image to emmc storage. However there's an issue when booting from vendor u-boot and the mainline kernel under high I/O load (e.g. when writing the image) where the kernel deadlocks and this can leave you with broken u-boot. It's not impossible to recover from, but needs Amlogic burning tool or UART cables (the UART port is on the rear of the pro box) and a lot of faffing about to kill vendor u-boot to force boot from SD card. I've not tested it, but a possible workaround is booting from CE (which doesn't have the lockup issue) and using 'dd' to write the image to emmc.
In general, anything with vendor u-boot should use the box image. I've mostly built the -beelink image to help the Armbian/Manjaro folks boot/run on the box using mainline u-boot to avoid the deadlock problem. LE still has the same issue, but since we are ultra-lightweight seem to mostly-avoid the problem. I had a sample shipped to one of the kernel maintainers to see if they can figure the issue out, it's beyond me, but it's a busy time of year so nothing was looked at yet. The same issue exists on all the Beelink S922X boxes.
