Posts by chewitt
-
-
Yes, 2.0.19 is the latest for Krypton
-
Select the "RPi2" image for RPi2/3 devices. If you download the RPi (0/1) image it will not boot and show the screen you describe.
-
The inputstream.adaptive add-on is in our add-on repo, so as long as you didn't manually disable automatic add-on updates, it has probably already updated, or a reboot will make sure that it does.
-
There is no 64-bit libwidevine library, only 32-bit, which is why future LE 9.0 releases have switched to the same split 64-bit kernel, 32-bit userspace arrangement as Android. Please also note that Google's license for libwidevine means it is not redistributable without signing formal agreements that result large liabilities for the signing entity. Community or personal LE releases that ignore the license and embed libwidevine for convenience will be suspended from this forum if we become aware they are doing so, because we do not want the legal attention that may result from their release here. There is a Kodi helper add-on for inputstream.adaptive that provides the libwidevine library via a user-initiated process. If it hasn't appeared in the Kodi repo yet, it will do soon - it's inclusion was agreed by Kodi developers at the recent Prague DevCon.
-
update was published earlier today
-
If you hear the clicks and whoshes from keyboard navigation Kodi is running but the default output (60Hz, 1080p) doesn't agree with the TV for some reason. You might need to experiment with changes in config.txt, see Raspberry Pi Documentation .. it has nothing to do with the SD card.
-
The pi-tools add-on contains several packages useful for GPIO things. There are also threads in the forum from users wiring up on/off controls. The GPIO pins might be different for you, but there's probably some prior-art to crib something from.
-
Things should improve once development builds reach the 4.14 kernel
-
No idea what's needed, but in LE the custom xorg.conf is located in /storage/.config/xorg.conf .. then reboot to effect the change.
-
It contains a Realtek RTL8814AU chipset which we have no drivers for, and no plan to add support for. We are basically fed-up with Realtek breeding chipsets on a monthly basis and with absolutely none of them receiving mainline kernel support; which means we would have to maintain the driver ourselves, and we have better things to do with our lives.
-
remove any matching entries from ~/.ssh/known_hosts and retry
-
LE is ~95% read-only and rather appliance like (deliberately) so you'd need to self-build and add the required user/group etc. at build time.
-
Normally the "getedid" command will detect the connected device and capture the EDID from it, then configure Xorg to use the captured .bin file to permanently force the detection. However that only works for a single output. If you want to swap between outputs you'll just have to remember to have the screen turned on before the box; or use the AVR to switch outputs without splitting audio/video.
-
If you're posting here .. it can be binned.
-
LE 9.0 does not exist. Development builds exist. Lots will change between now and LE 9.0 .. much depends on our community builders submitting their work to our main code repo instead of hoarding a boatload of patches. That said, don't expect miracles on Amlogic devices until we move up to a mainline kernel.
-
The two issues are kernel age and volume of devices. In dog/internet/linux years the 3.10 kernel is prehistoric and because it's missing so many now-fundamental structures it's too challenging to backport things. The 3.14 kernel is marginally easier, and unlike 3.10 there are a ton of devices using it, so community developers have made the effort.
NB: The second we have mainline kernel support for Amlogic devices, anything that cannot run mainline will have official support discontinued. The full scope of affected devices is not clear, but WP1 with the 8726MX chipset will definitely be dropped. Current ETA is post-Leia, so it should survive until the LE 9.0 release, although no promises.
-
1.) No, we have no clue what proprietary shitty SMB code runs in an ASUS router for their "share disk" feature (or whatever it is).
2.) SMB1 is considered a security risk. By forcing Kodi to continue using SMB1 you are still at risk. Disabling NTLMv2 auth over SMB1 (which is what those two lined do) degrades the already crap security level to something worse than plain normal SMB1. At the end of the day you are at no greater risk than you were six months ago. The only change is you (and many other users) are now marginally less ignorant of that risk, even if you don't understand it.
3.) The active SMB conf is documented clearly in the release notes that nobody bothers to read.