We do consider security issues, and the probabilty of a meaningfull exploit in the wild through LE devices is low. The attacker needs to be in the same network and most LE boxes are hidden behind NAT/firewalls, and if the attacker is already in the local network the HTPC isn't the target of interest and you have bigger things to worry about. In the past I've added some LE devices to instrumented honeypot networks alongside some well prepared deception assets. Most attackers shy away from the devices because they don't fingerprint as something known and recognised. The subset who did try to compromise the LE device generally succeeded with a dictionary attack on the well-known default password not vulnerability exploits, and then they all tried to drop a comprise toolkit into the OS, which fails massively due to our non-standard distro packaging, and they quickly gave up and moved onto other more promising targets in the environment. Plus, even if we rush out a release and push the update to the small percentage of devices that would receive it, the other 90% of our rather sizeable userbase will remain on something older with even more vulnerabilities. In the grand scheme of things and compared to the shenanigans that I see in my DFIR day-job, this is nothing to lose sleep over.
Posts by chewitt
-
-
You need to add the drive path as a source, then set content type and scrape the source (and hope media is structured and named correctly for scraping). I personally do that by editing /storage/.kodi/userdata/source.xml as it's easy to crib the format and miles easier using a real keyboard than o-n-e-l-e-t-t-e-r-a-t-a-t-i-m-e with the on-screen virtual one.
-
There are some Lakka devs in team chat, so I'll ask if they're doing anything different.
-
The wl driver is only used with a small handful of really old Broadcom SDIO chips. Newer designs are supported through in-kernel brcmfmac and brcmsmac drivers which are well supported and actively maintained.
Poor WiFI performance on RPi3B (and every other RPi board that I used) is a radio signal issue, not a chip or chip-choice issue. An external antenna connector would solve the issue, but I guess when you're intentionally cost-engineering boards for short-range hobbyist use there are design compromises to make, and perfomance comes second to cost.
-
It's a simple question with a non-simple answer. If you are playing H264 media the latest version works best. If you are playing HEVC media you will find the lack of hardware decode for HEVC on the RPi3 boards to be a challenge and shouldn't expect 1080p media to play well. Older LE 9.2.6 contains optimisations that (combined with some overclocking) allow most 1080p software decoded HEVC media to play, but those optimisations are not technically possible to include in the current releases and 9.2.6 is ageing so you may find issues with TLS certificates and older/unmaintained add-ons and online media sources may have challenges.
-
It was either Realtek RTL8189ES or RTL8189FS .. I forget which.
The wl driver has been unmaintained for years so hearing it panics doesn't surprise me. Share the report and a dmesg log in a separate thread.
-
The H4 should support EFI boot, which opens the door to using efibootmgr which can be installed from one of the tools add-ons in the LE repo (system-tools?). See https://linux.die.net/man/8/efibootmgr or https://wiki.gentoo.org/wiki/Efibootmgr. You would be able to combine efibootmgr with some custom buttons on a remote that configure the EFI boot entry to reboot to.
-
To confirm: You are saying that PCSX games work fine under Lakka on the same RPi4 hardware, but not under LE?
-
The upstream kernel does not expose the u-boot environment to userspace so there is no way to modify it to change the next boot behaviour. If you need that capability you are stuck with legacy vendor kernel images.
-
I usually rip disc's in FLAC for HiFi (AVR) playback with Kodi and then I rip again in 320Kb MP3 for phone/car use. I'm rotating the disks in the NAS roughly every 6-7 years and each rotation seems to cost the same but I end up with double the space I got in the previous one, so there's always space available. My priorities may be different to yours though.
-
https://chewitt.libreelec.tv/testing/LibreE…droid-c2.img.gz has a 5 second bootdelay set, which should pause boot waiting for input. If you hit enter/space it should enter the u-boot console and you can run commands. There no specific command to run; i'm interested in whether you can provide input or not, or does the board continue to stop/lockup at that point?
-
As per the wiki article, you need to invoke recovery mode boot on the box (toothpick method or similar) to ensure it looks for LE boot files not CE ones. If that's not the issue, we'd need to see UART logs of early boot to see where things go wrong.
-
Have you installed an online subtitles (source) add-on?
-
-
run "dmesg | paste" and share the URL .. WiFi should work on most devices depending on what chip is inside.
no issues with copy/paste here (on macOS)

-
Second boot from a hung board requires power cycling so it's technically no different from the first boot. The gibberish looks like a buffering issue to me, i.e. rubbish drivers for whatever USB UART cable. Using Windows? .. If using macOS the "Serial" app is the one to use (non-free, but worth it).
The only time I've seen boards boot and get stuck here is on some (but not all) WeTek Hub boards. The current suspicion with them is that noise on the UART connection (perhaps related to dry solder joints) is interpreted by u-boot as keyboard input and thus it drops to the console (although then the console must have some other issue to not be accessible).
I'm going to create a one-off image with the u-boot console compiled out or compile differently to see if that allows the device to boot. That might take a day or two to get around to, but I'll post a link when done.
-
CE should detect the installed image as "S912.arm" and image to update to as "AMLGX.aarch64" and since they do not match (and you have not manually overriden the update check) the update process should fail with an error message on screen, before erasing the (incorrect) update file and rebooting.
If you manually start trying to rename files on SD cards then it's possible to break stuff in other ingenious/exciting ways

-
Interesting, it's stopped at the u-boot console prompt. Are you able to run commands at the prompt, or has it locked up?