Posts by chewitt

    If it's crashing with the default skin then the issue is likely an add-on that's installed. The main approach to that is either disabling all add-ons and then (assuming that stops the crashing) you start reenabling them until you find the culprit; or you stop Kodi and move the current install out of the way (preserving it) so you restart with a clean setup. Now you can stop/copy/restart and progressively copy back stuff from the working install (or reinstall things) until you find the crashy thing. I personally prefer the clean-start approach as that generally exorcises or spring-cleans a pile of other Kodi related cruft that's accumulated over time too.

    From the description; the .deb package install requires sudo (root/admin) rights to be installed. It's not a backdoor password, but since it can be used to gain root rights on the host it's a credential to protect - hence the security best-practice advice of not using the same password for the admin user in TVH.

    I'd add a second Ethernet NIC into the PC and run a cable to the router that the RPi4 is connected to (ISP2) then set the connection priority in Windows to use the NIC that connects to the ISP1 router as the primary connection. As the PC now has IP addresses in both networks you will be able to download on the ISP1 connection but also connect directly to the RPi4 in the other network to upload/transfer files. If you can't run Ethernet, get a WiFi card and have the PC join the WiFi network from the ISP2 router. As long as you set the connection priority for the NICs it will work the same (only slower than Ethernet). NB: For this to work, the routers must distribute IPs from different IP subnets, e.g. ISP1 router uses 192.168.1.0/24 and ISP2 router uses 192.168.2.0/24. If both routers use the same subnet the IP ranges will conflict.

    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.

    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 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-legacy

    That'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.