Posts by chewitt

Yes, as long as the BT chipset in the dongle is recognised by the kernel and results in BT drivers being loaded. It's never 100% guaranteed but these days most devices use known/generic BT chips and should work.

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

Yes, as long as you have no plans to downgrade back to the earlier release (If yes, make a backup first).

If you're seeing the Kodi splash things are up/running so you can SSH in to check kodi.log and see what's going on (or not). If there's not much info (as not in debug mode) and you have local DB files then it's possible to stop Kodi, add content to advancedsettings.xml for debug mode, delete the Nexus DB files, then restart kodi to reinitiate the update; but this time you'll see more info in the log to find the issue. If you have an external DB then it's the same process but you'll need to drop the tables in the DB to force the update process to restart.

2023-09-24 06:20:36.613 T:1937285696  NOTICE: Using Release Kodi x32 build (version for Raspberry Pi)

Changing that URL to HTTP (as ix.io does not use HTTPS) shows ^ which definitely didn't come from an Acer PC

I would recommend testing/using LE12 nightlies as those have much newer kernels and mesa code.

Quote from thegooddoctor

the new u-boot loader is what is faulty --- and I don't know why it is being used if it is known to be problematic

Wrong. The user hardware is faulty, which creates noise on the UART which is interpreted as keypresses causing boot to be interrupted.

Stats show a reasonably number of AMLGX installs on Hub hardware, though I have no way of knowing whether people are using the upstream u-boot image or the box image

I've been busy tinkering with something else recently so didn't find time for building a tweaked u-boot version. Soon insh'allah.

Quote from N4OZ

No success despite repeating these steps. I have plenty of free memory and the CPU is idling along with no load. What am I doing wrong?

You're wrongly assuming that LE follows normal Linux distro packaging conventions. It doesn't (intentionally). If you really want to run a Plex server on the same device as a Kodi playback client, install the Docker add-on and investigate running Plex server in a Docker container. I'm not aware of any LE specific howto guides/writeups for this, but Docker is Docker.

Quote from salvador

My wifi is ok.

Not according to the log snippet shared (which is too small to really diagnose anything from).

Fix your network problem?

Please remove the EDID config.. I don't believe it's relevant to the issue. Then update to this image:

https://chewitt.libreelec.tv/t…EC-gbm.x86_64-11.80.0.tar (update existing install)

I've changed the kernel patch to add a different quirk type (based on the thread Da Flex found). Cross fingers and roll dice

You can use the LE USB/SD app to create the image, or Win32DiskImager, or other similar apps. You can experiment with another SD card. If it's some kind of repeating issue when you use a different app and/or card then it's something massively obscure but local to your specific box. Active install stats for the project show me that there are enough people using the AMLGX image and/or with S905X devices to know it's not a general issue with the image.

Quote from AdrielHoppe

I am facing an issue can ia ask a question?

If you want an answer it would be a good idea

According to https://github.com/xbmc/xbmc/blob…eyboard.xml#L95 backslash toggles between full-screen and windowed mode; which in LE will just result in some kind of screen reset/refresh as there's no windowing environment and we force Kodi to run full-screen all the time. I've never personally used it, but if you install the keymap editor https://kodi.wiki/view/Add-on:Keymap_Editor you should be able to (re)map the key to something else or remove the command. The same can also be done from the CLI by downloading the default keymap from GitHub to /storage/.kodi/userdata/keymaps/ and editing there.

I'm struggling to recall seeing that kind of issue before so I'd chalk it up to something random on your box (or SD card). If it was a proper bug in the OS we'd expect to see a large number of user reports. Odd..

The developer who was contracted to work on the decoder went down the rabbit hole of persuing a stateless implementation. This would be awesome to have since it means no closed-source firmware blobs, but it turns out Amlogic doesn't expose a bunch of low-level stuff needed and this was not discovered until he'd already burned through 4-5 months worth of funding. There is still a strong commitment for further work (starting over with a stateful implementation) but right now the war-chest is lacking funds and we'll need to wait a while until business profits refil the coffers. It's annoying, but c'est la vie, this kind of setback does happen.

I wouldn't expect any real-world changes from LE11 images to LE12; ffmpeg and Kodi evolved a little but the underlying kernel is currently the same and that's really what dicates how things behave. I'm working up enthusiasm for a bump to Linux 6.5.x but most of the development in the kernel since Linux 6.1.x is refactoring (rearranging deckchairs on the titanic) and the early stages of adding support for new hardware generations (but nothing we'll be able to use).

I have no interest in aarch64 LE11 images. You can try to create them yourself, but there were build issues when LE12 first switched so you'll probably hit issues and need to backport things. IMHO it's not worth the effort. And LE12 nightlies will eventually turn into LE12 release images .. but with the same LARGE BOLD TEXT warnings on state and usability (nothing has really changed). The number of people using the AMLGX images continues to increase with time, but the image won't flourish without better decoders, and chasing user numbers has never really been a personal motivation or team objective.

As already hinted.. "git grep mesa-demos"