It's not that there's no interest, it's just something that's proven difficult to resolve (there are multiple attempts). RPi4 doesn't use MMAL decoding these days, so that's only applicable to older RPi devices and older LE/Kodi releases.
Posts by chewitt
-
-
No idea, we will be using somewhat default Qt options and if there's a change it will be something Qt releated. Nobody on the project staff has much of a clue about Qt - which is why it's taken 2.5 years to respin an updated version of the app. If you can find someone with Qt skills who can take our sources and tell us explicitly what's wrong and needed to support Win7 (without breaking everything else) we'll re-add support. Anything that involves project staff needing to skill up on Qt to fix it won't happen (see prevous 2.5 years comment) and there's a lot more fun, interesting and needed things to do around the project.
-
I have a hunch the version of MariaDB (5.5) is too old. Perhaps try bumping that too.
-
As the screenshot also shows the addons folder size at a looks-correct 286MB value I'd guess "Windows is crap" ..
-
In short, nothing exists. I'd guess because people are either sat in-front of the computer running Growl *or* sat in-front of the TV watching something on the HTPC device. We have no package manager in the OS so you can't just install it. However, if the gntp-send binary is simple you might be able to simply copy it over from, e.g. RaspiOS, but if not you'll need to find a docker container (overkill, but works) or self-build a custom LE image with the package added - there are rather deliberately no instructions for that kind of thing.
-
I meant pushing to your own repo. All looks good, nice to see the work being shared
-
extremeaudio have a look at https://wiki.libreelec.tv/configuration/…figuration-hard .. the article needs an update to reflect the "toml" format being used with ir-keytable now, but basically it's the same process. Despite the "Configuration (Hard)" title, it's not that hard to capture the keycodes and create a custom keymap file. Lots of prior art (and all the kernel IR keymaps) can be found in /usr/lib/udev/rc_keymaps/ .toml files.
-
The best way to avoid HDR > SDR issues is to handle the conversation at the ripping stage, then you have SDR files.
-
I am totally new to this and was wondering what image you used and what dtb file you chose? I also have a x96 max plus 4gb/64GB android tv box im no longer using and would like to turn it into a pihole appliance... I'd even appreciate advice on if this is the best version of linux for my box to choose? (no offence) to use with pihole etc...
Create the USB from the AMLGX "box" image in https://chewitt.libreelec.tv/testing and then set the dtb name to use in uEnv.ini and trigger recovery boot (most boxes follow the toothpick method) to force u-boot into reading alternative boot scripts that load LE. We have no package management so to install PiHole you need to install the Docker add-on in Kodi and then run a PiHole container. For that reason you might want to look at Armbian instead of LE, as this will give you a conventional debian package manager to work with.
-
Hi I have a beelink m18 s905 with a old libreelec 7. Is there any chance to upgrade to a recent release? if yes how. Thank you
Two options. Either have a look for dtech legacy images LE-9.2.8 builds for some Amlogic S905x, S802/S812 and S805 devices which gets you to LE 9.2.x with K19, or boot the LE11 "box" image from https://chewitt.libreelec.tv/testing/ and see what S905 device-tree files (configured in uEnv.ini) get things working best. With the second option you will need to force recovery boot again to load new/different boot scripts. The LE11 images aren't quite as functional as legacy, but are still usable, and K20 is the future.
-
I use an AV-Receiver between my TV and the odroid - I think it intercepts and changes the EDID data.
I would like to get the original EDID data and reuse it -> https://wiki.libreelec.tv/configuration/edid#amlogic-legacyThat's old though, since we don't use amhdmitx but instead lima.
tvservice binary is also not available, so I have no idea how to retrieve the edid data...
I'll have a look at what's needed to adapt the "getedid" scripts for RPi to work on extlinux ARM devices. Until then you can follow the Intel GPU guide in the wiki, it's generally applicable for all hardware using the kernel 'DRM' subsystem (which is everything these days).
-
There are active conversations about how to add new/more build servers and rework our use of Jenkins or move to a GitHub actions based workflow. The main goal is to substantially increase build capacity so we can build more stuff more frequently; our master branch nightlies are not nightly at the moment, and (as you commented) there is no coverage of the release branch. The secondary goal is to keep built images for a much longer period of time to help with regression tracing.
-
To point out the obvious: video=HDMI-1:640x480@60iD isn't going to help much with composite output. I'm not 100% sure of the connector name, but it's probably CVBS-1 ??
-
I'd guess that after power outage the RPi is being booted before the HDMI source (AVR or TV) is on, so we don't detect it and fall back to the default Pulse (BT) output. It's fixed by powering up devices in the correct order (HDMI source first, then RPi) or worst-case by caching EDID data from the HDMI connection and configuring the kernel to read the cache at startup so it believes the HDMI source is connected.
IIRC .. run "getedid" from the console.
-
I'd suggest you post for help in the Kodi support thread for the YouTube add-on .. it's not really an LE issue and more (relevant) people will see the issue there.
-
However when I play content 4K 60hz it sometimes drops out, for half a second the image gets black an reappears. Even in the GUI it shows this behavior. With the 30hz settings it behaves normally as intended. So is my NUC too slow to display 4k at 60hz?
Unless there's some driver issue (that we won't know about) the GPU and DRM drivers should handle 4K@60 fine. However 4K@60 requires considerably more bandwidth on the HDMI connection so the common weak-link is the HDMI cable. Pretty much any old crap HDMI cable will handle 4K@30 but "certified" cables and sometimes specific HDMI ports on the TV are required for 4K@60.
-
It might be worth experimenting with an LE11 test image from https://test.libreelec.tv .. newer kernel and drivers might resolve something?
-
There are issues with ISO files in some releases (long-running battle). Have you tried a current K20 dev build? https://test.libreelec.tv/