Posts by chewitt

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"

Camera devices have no use to Kodi so the LE kernel does not enable them. Hence "lsusb" shows the device as present on the bus, but in the absence of a kernel driver nothing more happens. If you're the tinkering type, you can self-build an LE image with the required driver enabled. Have a read here: https://wiki.libreelec.tv/development/build-basics and here: https://wiki.libreelec.tv/development/git-tutorial

LibreELEC.tv/packages/graphics/mesa/package.mk at 10.0.4 · LibreELEC/LibreELEC.tv

Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.

github.com

LibreELEC.tv/packages/linux/package.mk at 10.0.4 · LibreELEC/LibreELEC.tv

Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.

github.com

Use the branch/tag selector to move to another (release/tagged) point in Git history. Use "git grep" to find things in build-system sources. The "mesa-demos" package provides glxinfo.

Turn all devices off and physically disconnect HDMI cables. Go make a coffee and leave it alone for 15 mins. Reconnect cables and power things on; the TV first, then the RPi4. Any change?

You'll see that screen if the bootrom cannot find an OS to boot. It can see an SD card is inserted, so I'd hazard a guess that the card has some kind of issue (or has failed). To narrow the problem, grab a spare SD card and create a new install, and see if that boots?

Please test this image:

https://chewitt.libreelec.tv/testing/LibreE…-11.80.0.img.gz (install/run from USB drive) or

https://chewitt.libreelec.tv/testing/LibreE…_64-11.80.0.tar (update existing install)

Share "pastekodi" results after, thanks.

The mostly likely cause (and unfortunately the hardest to debug) will be "some radio issue in your environment" .. it could be interference or loading on the AP or proximity to other devices or too-strong a signal or ..

To investigate you'd likely need to run iwd in debug mode, which will generate mountains of debug log output, which probably nobody on staff will really understand (as none of us are wireless engineers).

Pi is close-enough to run a short cable? Ethernet really is the best solution to WiFi problems (though never the answer people want).

There is no "make default" command or "set as default" that you can put into ConnMan service files. You can however use connmanctl to change the service order, moving a service up or down the order. I'm not sure if the first configured gets the route or there's other black-box magic involved. You might want to email the ConnMan mailing list to get answers on that kind of question.

I have a hunch it's this https://github.com/xbmc/xbmc/issues/23622 albeit with a slightly different use-case/presentation. If I'm right, it's not technically a bug since current Kodi GBM code is working correctly. The issue is that current Kodi GBM code doesn't handle enough rotation scenarios. The reason it stopped working is due to RPi images swithing to the GBM display pipeline (moving away from proprietary code to standards in the now-upstream kernel).