Posts by chewitt

Add-on issues are rarely OS specific but you could prove that by testing the add-on under Kodi on RaspiOS instead of LE. If the issue exists there too you can focus on the Twitch add-on and log issues with the add-on devs via the support thread in the Kodi forums.

I'd also suggest using LE12 to see if anything is different. Development for LE and Kodi has been focussed on Kodi Omega for a while now and even if there's a bug found, the fix will go into LE12/Omega first.

Pinned for visibility..

I'll probably just add the script (with an edit to L20) and see what issues are unearthed.

The DXxxRenderers config probably has no effect as DX display drivers are a Windows thing. Enabling GL should be be the only config item to have impact, though I'm wondering if that truly means GL (only)? as GBM images are using GLES not GL (as shown by logs that heitbaum shared).

If you see anything like "needs the official PSU" written in documentation this is simply meaning "needs a PSU with the capabilities of the official PSU" as there is 100% no hardcoded requirement or secret handshaking to check whether the user has an official RPi branded PSU. RPi != Apple

The /storage/.kodi/userdata folder where most thing you might need to access is shared as //LIBREELEC/Userdata, but the Kodi root folder in /storage/.kodi is not shared by default. If you want to change that for some reason, you need to access //LIBREELEC/Config and edit the samba.conf.sample file to add a new share (crib the format from existing entries) then rename the file to samba.conf and reboot. On restart the new config will be used instead of the default one and the extra share you added will be accessible on the network. Or use an SFTP client like Filezilla/CuteFTP which can see all files and directories on /storage easily instead of SMB.

NB: Enabling hidden files/folders in Kodi settings does not help with remote access to the local Samba shares.

Quote from justnowsigningup

I'm trying to get LE to run in Virtualbox so that I can do all my configuration, add-on installation and setup, etc., then convert the .vdi to an iso that I can then plop onto the few raspberry pis I have running LE. Is this even possible?

You can probably run or directly import the Generic OVA image we don't support (but is available) for vmware into VirtualBox; staff are mostly using vmware but there are other people who use VB. That will avoid the need to create an ISO version of our installer .img which likely won't work anyway due to all the paths being wrong. NB: You could create an installer USB as-normal and then boot the VM from that to install to the internal VM disk (as normal) .. would be much easier.

However the VB setup is x86_64 and your RPi2/3 boards are armv8 so even if you abandon the idea of "converting the image to use on an RPi" (which is technically not possible due to different CPU architectures) and do a simple "backup /storage and restore /storage" you will still find that there are config differences due to Intel and RPi hardware being different, and binary add-ons that you backed-up will not be compatible (due to wrong CPU arch again).

In the end the amount of effort/energy expended trying to do this "the clever way" will be far greater than just setting up a couple of RPi boards the un-clever/normal way. Set-up one board and then learn to "scp" the important bits of /storage/.kodi to the others and you can replicate the config in 10mins per-board.

First update the vmware hardware version on the 17.5 version, and if that makes no difference, then do that.

I'm running a Marantz SR7011 since 2018 (was discounted as old stock when something new came out) and when that finally dies of old age sometime in the next decade I'll do the same again; find something Marantz in the upper mid-range of their lineup from the previous 18-months which had a great rating and is now on-sale somewhere. These days I'm only using 5.1 output (else there's too much cable everywhere) and I use PCM output in Kodi to avoid needing two remote controls. Perhaps it's old(er) age but these days I'm content to have something that sounds good (with Kef Reference speakers) that "just works" instead of pushing the boundaries of Linux media; or perhaps the boundaries (and an RPi5) just caught up with what I'm happy with and need?

RPi5 has greatly improved CPU decode capabilities over an RPi4 so it can e.g. handle some AV1/VP9 content, but otherwise doesn't really add anything over an RPi4, e.g. HEVC capabilities are identical.

HDR10+ is typically backwards compatible to HDR10 so you'll see "HDR" output on that content. DV content is sometimes backwards compatible with standard HDR and othertimes requires hardware with dedicated DV capabilities; which limits you to devices that run Android or Windows and are outside the scope of this forum.

For kicks, can you update the 17.5 system to a currently LE12 nightly and see what happens?

#!/bin/bash

# SPDX-License-Identifier: GPL-2.0
# Copyright (C) 2022-present Team LibreELEC (https://libreelec.tv)

do_install(){
  # create the persistent firmware dir
  mkdir -p "/storage/.config/firmware/edid"

  # capture the raw edid file
  if [ ! -e /storage/.config/firmware/edid/edid.bin ]; then
    cat "/sys/class/drm/card0-HDMI-A-1/edid" > "/storage/.config/firmware/edid/edid.bin"
  else
    echo "info: using existing edid.bin"
  fi

  # create the cpio file
  mkdir -p "/storage/cpio/lib/firmware/edid"
  cp "/storage/.config/firmware/edid/edid.bin" "/storage/cpio/lib/firmware/edid/"
  cd "/storage/cpio" || echo "error: cannot find /storage/cpio .. exiting!" && exit 1
  find . -print | cpio -ov -H newc > "/storage/.config/firmware/edid/edid.cpio"

  # mount /flash rw
  mount -o remount,rw /flash

  # copy the cpio file
  cp "/storage/.config/firmware/edid/edid.cpio" "/flash/edid.cpio"

  # cleanup cpio dir
  rm -rf "/storage/cpio"

  # determine boot method and set params
  if [ -f "/flash/extlinux/extlinux.conf" ]; then
    FILE="/flash/extlinux/extlinux.conf"
    if grep -q "initrd=/edid.cpio" "${FILE}" ; then
      echo "error: ${FILE} already contains edid.cpio, aborting!"
      exit 1
    else
      cp "${FILE}" "${FILE}.backup"
      sed -i "/ APPEND/s/$/ drm.edid_firmware=edid\/edid.bin video=HDMI-A-1:D/" "${FILE}"
      echo "info: edid setup complete!"
      exit 0
    fi
  else
    FILE="/flash/uEnv.ini"
    if grep -q "initrd=/edid.cpio" "${FILE}" ; then
      echo "error: ${FILE} already contains edid.cpio info .. aborting!"
      exit 1
    else
      cp "${FILE}" "${FILE}.backup"
      sed -i "/ bootargs/s/$/ drm.edid_firmware=edid\/edid.bin video=HDMI-A-1:D/" "${FILE}"
      echo "info: edid setup complete!"
      exit 0
    fi
  fi
}

do_cleanup(){
  rm "/storage/.config/firmware/edid/edid.bin"
  rm "/storage/.config/firmware/edid/edid.cpio"
  mount -o remount,rw /flash
  rm "/flash/edid.cpio"
  if [ -f "/flash/extlinux/extlinux.conf" ]; then
    FILE="/flash/extlinux/extlinux.conf"
  else
    FILE="/flash/uEnv.ini"
  fi
  cp "${FILE}.backup" "${FILE}"
  mount -o remount,ro /flash
}

do_usage(){
  echo "usage: getedid {create|delete}"
  exit 0
}

case $1 in
  create)
    do_install
    ;;
  delete)
    do_cleanup
    ;;
  *)
    do_usage
    ;;
esac

exit

I created ^ that some time ago to replicate the "edid-create" process for other boards (which never seemed to quite work) but it's not something that I was able to test easily so it hasn't been upstreamed.

Copy to /storage, make it executable, then run "./script.sh create" and see what happens.

There is no ISO image and LE cannot run from an ISO image (so you can stop looking for one). If you want to install to spare space on an existing disk this can be done, but it's not a supported configuration so you won't find nice HOWTO guides and instructions for setting something up. Grub will work fine (we don't care what bootloader is used) if you configure the boot entry correctly; see contents of syslinux.cfg for ideas. LE requires two partitions; one for boot files (512MB) and one for persistant storage (8-16GB min) assuming media is stored somewhere else.

I have a hunch Ubuntu/Fedora are using OpenGL (via Wayland) while LE/Generic is using OpenGLES, and thus the difference being seen is due to differences in GL vs GLES capabilities (and thus not technically a bug) but I'm not 100% sure.

Quote from elliottmc

you will probably get a much better experience if you use a NAS for storage

You have wrongly included "probably" in that statement

Use snapshots or clone the disk for experiments. Are you mapping the GPU in the VM or using the vmare GPU?

Read: https://wiki.libreelec.tv/hardware/amlogic#install2internal

In the absence of UART logs that show what actually happens during boot it's impossible to comment.

It's possible if you compile a custom image with a different busybox configuration. Otherwise, no. The better option to remove complexity is using SSH key authentication; then no passwords are prompted-for.

The "Generic" image switched from Xorg to GBM graphics but IIRC the vmware GPU in the OVA should support that. However if the host GPU has been mapped through to the VM this will 100% fail on nVidia cards as there is no support for them without Xorg.

NB: I've been told the virtual hardware version of the OVA needs bumping for Workstation 17.5 (and likely other recent versions) but that something which can be tweaked locally.