This forum does not discuss or provide Android firmware, please use freaktab or similar.
Posts by chewitt
-
-
It looks like the rtl8188ee driver in the kernel is pci only, not usb, so nothing is showing up. This means you'd need the realtek vendor (not in kernel and breaks on every kernel update) driver .. and we've a long history of refusing to add them because they're a pain in the rear to maintain over time.
-
Put LibreELEC-AMLGX.arm-9.80.0.tar in /storage/.update/ and reboot, then run "dmesg | paste" and share the URL after it's rebooted (no need to copy/paste to pastebin). The image has a newer kernel with more realtek drivers enabled - and we can see if the card is detected. NB: If it is the card probably won't work due to missing firmware, but the log should should which firmware.
-
You can experiment with the AMLGX test images on https://test.libreleec.tv using a different SD card, but you will need to experiment with device-trees (Tanix TX3 is another S905W device and might work) but the images are still not ready for prime-time use yet so it would probably be better to stick with the current image and use OpenVPN.
-
There is some progress on HD audio (not specifically about Atmos) but things are still not at the stage where things should go into public images for general consumption. And video things still have priority over audio.
-
The 4K@50/59.94/60 modes will not appear unless you force "hdmi_enable_4kp60=1" in config.txt, but since the GUI runs best at 1080@60 (as the TV will upscale 720/1080p skins to 4K better than Kodi can) and 99% of 4K media is [email protected] .. is there any actual reason to enable it? As a rule the answer is no, which is why this is not a default option.
-
WireGuard support is still new and somewhat experimental and there are some systemd changes being figured out (slowly) in another forum thread to ensure more reliable connectivity. The issue of DNS leaking in known but also not something that will be simple to solve. The issue is that connman will append DNS servers specified in the wireguard config file to /etc/resolve.conf but it will not remove the existing nameserver at the same time because connman does not "manage" the DNS servers. As a result, traffic will route through the tunnel, but DNS will still resolve through the local nameserver as this is still the primary (first listed) nameserver. Resolving [sic] this probably requires a switch to using networkd (part of systemd) which is a non-trivial change for the distro to make, and isn't likely to be done anytime soon. The next-best thing is to write a handler script to remove (and cache) and then restore (from cache) the DNS servers, but there are multiple ways to change network properties while a wireguard tunnel is up, which might alter the list of nameservers, so it's one of those things that sounds simple but is programatically complex with a load of caveats on realiblity. More serious investigation on the changes needed to eliminate DNS leaking are not on my personal to-do list right now; because WireGuard works reliably for me, I don't have much time due to a busy work schedule, and the DNS leak is not important for the personal use-case that I implemented WireGuard support for. Sorry if that sounds rather "not interested" but .. I don't have the time to deal with it so the community at large will need to contribute to solving it.
-
The first-run wizard allows you to enable SSH and disable Samba sharing. Samba is on by default and you did not turn it off. Go visit the services section of the LE settings add-on if you do not want that info available over the network.
-
It would be good to tell us which card. We suck at guessing
-
RPi3 hardware does not support any of the HD formats (TrueHD, Atoms, etc.) although you should get the 5.1 core on media that uses HD audio (what plex will be doing). RPi4 supports it in hardware but not yet in software.
-
Firmware is updated and the issues should be resolved or significantly improved.
-
The entire OS is contained in two files (KERNEL and SYSTEM) and then we delete the .tar file and folders we extracted those from.
-
I'm fairly sure that Google won't remove widevine support from or kill updates to ChromeOS, so that route will always be open. It would be a lot easier to redistribute the extracted files as-is, which is permissible, but by doing so you accept Google's license terms. To say they favour Google is rather a large understatement, and punitive is probably a good word for them.
The libs allow Kodi to access DRM protected content by pretending to be a web browser.
-
Probably best to ask in the Plex add-on thread in the Kodi forums, or start a thread on JSON-RPC things; it's nothing specific to LE.
-
The primary goal for the initial launch codebase on RPi4 (Linux 4.19) is to not regress/break anything. All development focussed on pushing forwards to better performance and new features like HDR is focussed on newer kernels and GBM/V4L2. This is currently based on Linux 5.4 and we are close to switching LE master branch (will be LE10 in the future) testing to this codebase. Tearing has been resolved in the future codebase for some time.
-
IIRC sftp support was removed from core and reimplemented as an add-on.
-
I'm pretty sure, that's a copy and paste from a release nearly 6 months ago, isn't it
CvH you've been rumbled
-
Google only publishes 32-bit libwidevine for Linux/ARM use and even that has to be extracted from a 3GB ChromeOS update image. There is no 64-bit lib that's ever been found, and we haven't ever managed to use the 32-bit lib in 64-bit userspace via compat tools. So we can either build images with 32-bit userspace and facilitatte access to Amazon, Netflix and a number of other DRM oriented streaaming platforms, or we can give a marginally better performing 64-bit userspace without them. As much as DRM sucks balls, it's a fact of life in the world of legal streaming, and we (and Kodi) would prefer to encourage use of legal streaming services than create yet-another obstacle to encourage use of pirate services.
