Posts by chewitt

    The ssh boot param still works. If set you cannot disable/enable the SSH service in LE settings. Note that if you want to use USB for /storage the USB needs to be correctly partitioned with EXT4 or another supported *Linux* filesystem. If it's FAT or NTFS the filesystem doesn't support unix permissions and contents of /storage default to 777 which means the SSH private key in /storage/.ssh isn't secured (it's world readable) and the SSH daemon will preventatively refuse to start.

    AMD dropped VDPAU (because it doesn't support 10-bit or HEVC and nVidia no longer maintains it) and switched to VAAPI which already has DRM/KMS and GBM support from work done by Intel for their own GPUs (which means VAAPI is no longer a proprietary single-vendor thing so it's saved from execution in k19). I'm not aware of all the details but it would be reasonable to assume the newer driver supports the majority (but probably not 100%) of the current devices.

    NB: It should still be possible for nVidia users to switch to another distro that supports X11 or Wayland which can hook into NVDEC support in FFMpeg. It just won't be possible to continue with 'official' LE once we remove X11 as the DRM/KMS architecture needs GBM (which nVidia does not support) or someone has to go implement EGL Streams; which is entirely possible but unlikely to come from current LE/Kodi developers who are rather fed-up with proprietary nVidia stuff. If someone wants to implement it, they need to have a thick skin to deal with comments on the submission and they need to be committed to long-term supporting the code. If there's a hint of expecting Kodi developers to maintain it there will be impolite responses from Kodi's lead architects :)

    Nothing changed. Kodi (still) defaults to anonymous/guest auth unless a credential is used. If the Windows end supports anonymous auth things will work. If it doesn't (which is increasingly the case) the user needs to use a credential. As it's impossible for us to guess Windows configuration from the typically illiterate descriptions we receive we advise everyone to use a credential; which is also the best advice for security.

    Hi! I'm new in the forum, but I thought giving my 5 cents about this LE image was worth the subscription :)

    I've checked it with an orange pi pc plus (wifi, 8GB EMMC), with a 16 GB, chinese class 10 SD card, for some minutes

    I had quite a lot of artifacts decoding some h264 files, not too much with some h265, only installed **PIRACY** addon (worked OK), good ethernet speed. Right now it's not totally usable if you get artifacts/glitches in all h264 videos, but it's really good.

    The addon you installed is a piracy addon. Go read the forum rules.

    Create a script that checks at 1 second intervals for the drive being mounted or until a suitably large timeout value is reached, and then create a systemd service required by the Kodi service to run the script. The combination should see Kodi 'delayed' until the drive has mounted.

    GBM/V4L2 is all about laying the technical groundwork for the future of Kodi on Linux. Kodi today is not really designed for the 4K media that is slowly becoming mainstream, and it's a massive technical effort (and reinvention of the wheel) to support new hardware. It's unlikely that these changes will deliver significant tangible benefits for the devices of today (particularly with Pi hardware which already has very heavily optimised software). You'll see the benefit in future devices; because a) they will be possible, and b) you'll have a wider choice of devices that are more 'open' and better supported than before.

    At the moment devices that need to do an aarch64 > arm change like WeTek Hub/Play2 and Odroid C2 aren't showing a manual update option because the settings addon filters the list of available options according to the current device/arch. An experiment needs to be done duplicating and renaming the arm image so it has an aarch64 filename (e.g. LibreELEC-Odroid_C2.arch64-8.90.004.tar) then rebuilding the JSON data file. The update process isn't sophisticated enough to detect that the file is a different arch so it will just download/unpack/reboot/update as normal and you should get the same result.

    NB: I'd go test this myself but I'm currently on vacation and can't .. but one of the other staff should be able to check the theory.