Posts by chewitt

"It depends" on how much customisation you've done as the backup function only back's up the /storage/{.cache|.config|.kodi} folders, so if you dumped other things elsewhere on /storage they will be missed.

If you manually wget the RPi5 update file to /storage/.update and then "touch /storage/.update/.nocompat" to disable the checks we do to prevent wrong-image updates you can reboot to update the RPi4 to the RPi5 image. The first stage of update (changing files) will work. The second stage (booting) will probably fail as the RPi5 kernel will have RPi4 things missing. At that point or when the board shuts down to reboot, pull the power, move the card to the RPi5 and power on. Take a backup first and move it somewhere safe, in case somthing goes wrong.

There is no SSH console config/help tool. There are reset functions and log-generation options in the LE settings add-on (in the GUI).

You can self-build the image with an older kernel and firmware source. I doubt you will find anyone volunteering to build you custom images though. Instructions on self-building images are in the wiki. Start with creating a current image, then modify the package.mk for the linux and related firmware packages.

Your message is "Lost in translation" ..

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

PKG_NAME="drm-vc4-grabber"
PKG_VERSION="a0ed242818109d4d7f8bba4830878ce647b6c878"
PKG_SHA256="f5db271b1ddc3dad40477168c1404bbeb4c29e585aaac785926e49462147c596"
PKG_LICENSE="UNKNOWN"
PKG_SITE="https://github.com/rudihorn/drm-vc4-grabber"
PKG_URL="https://github.com/rudihorn/drm-vc4-grabber/archive/${PKG_VERSION}.tar.gz"
PKG_DEPENDS_TARGET="toolchain cargo:host"
PKG_LONGDESC="Raspberry Pi DRM-VC4 grabber for Hyperion"
PKG_TOOLCHAIN="manual"

make_target(){
  export RUSTC_LINKER=${CC}
  cd src
  cargo build \
    --target ${TARGET_NAME} \
    --release
}

If someone wants to experiment further, create packages/addons/addon-depends/drm-vc4-grabber/package.mk with that ^ and then build the package (only compile tested). You'll need to recreate the systemd service and/or figure out further packaging to get things working. For me the binary ends up in build.LibreELEC-RPi5.aarch64-11.80.0/build/drm-vc4-grabber-a0ed242818109d4d7f8bba4830878ce647b6c878/.aarch64-libreelec-linux-gnu/target/aarch64-libreelec-linux-gnu/release/

The minimal content you need is sources.xml, passwords.xml, and guisettings.xml; the latter will have changes specific to a specific hardware type (as RPi has differences to an Intel GPU device etc.) but things are mostly portable. I have 'master' files and a setup bash script stored on a webserver so I can clean-install something, wget the script and run it to configure a clean device for test in a couple of minutes. You probably don't need to go that far though

Running "PROJECT=Generic DEVICE=gbm ARCH=x86_64 scripts/build qtbase" (or the equivalent for other platforms) will build only that package (and any dependencies needed for the package itself or compiling, i.e. the toochain). The current qtbase package.mk probably doesn't pick any of the binaries or library files into the LE image (looks like it's only a compile dependency for Hyperion, I didn't look hard at how it's used) but adding files would be a simple change to make; most package.mk files in our buildsystem do add files so there's lots of prior art to crib how that's done from.

If the long-term intention is to use skyscraper with LE, it's probably worth investing a little time/effort into creating a skyscraper package for our buildsystem. The workflow for compiling is a little different if you're used to working with a conventional distro; though the underlying cross-compile process is the same. Working with a package within our buildsystem will eliminate compat issues that sometimes arise due to differences between e.g. Ubuntu and LE runtime environments, and will also make long-term maintenance easier. Once the intial work to create the package is done you can simply keep your changes in a topic branch and rebase/bump and rebuild skyscraper against later LE releases as needed. Once you have a stable image a quick respin is often a couple of minutes compile time, not a full multi-hour experience.

I'm honestly not sure how I "play" a png file in Kodi?

EDIT: After enabling photos and using "files" to navigating to the dir with the png file the red and magenta bars are showing fine but the text labels for them are not as sharp as the other colours.

Some of the code snippets in the XDA thread mention "s4" which indicates the box has an S905X4 chip. At the current time there is no upstream kernel support for S4 devices. Amlogic started to usptream patches but their staff are lacking experience with kernel coding standards so the process is glacial because each patchset requires many iterations. You probably want to look at CE not LE as their releases are based on the Android vendor kernels.

There's been a few reports of missing HD audio but I haven't had time to investigate. There are mentions on other hardware too so perhaps something changed on the Kodi side and not the kernel for once.

Quote from MIKMXIII

I don't understand why connected via blouthoot my saundbar has better audio than connected via jac 3.5 with the libreelec box

The analogue output DACs used with the 3.5mm jack on most Android boxes are a cheap afterthought. The DAC in the soundbar simply does a better job with the same digital input.

The qtbase files are compiled and packaged alongside Hyperion binaries in the Hyperion add-on package, they aren't included in the base image. If you add "qtbase" to https://github.com/LibreELEC/Libr…EC/options#L259 the files should be available?

That's annoying. I've pinged the upstream repo again.

If you share something, yes.

Feb 16 18:10:58.938125 LibreELEC kernel: ntfs3: sda2: volume is dirty and "force" flag is not set!

You need to clear the dirty filesystem state with chkdsk.exe on Windows before the kernel can mount the NTFS filesystem the drive uses.

Hyperion has no support for the GBM/V4L2 display pipeline that LE uses with Kodi. See https://github.com/hyperion-project/hyperion.ng/pull/1422. Until that PR revives/completes you will need to use an external hardware grabber.

[Unit]
Description=TVHeadend43 Service
After=network-online.service

[Service]
ExecStart=/bin/sh -c "exec sh /storage/.kodi/addons/service.tvheadend43/bin/tvheadend43.start"
ExecStartPost=/usr/bin/sleep 10
TimeoutStopSec=2
Restart=always
RestartSec=2
StartLimitInterval=0

[Install]
WantedBy=kodi.target

Kodi start already depends on service.tvheadend.service but if you modify the service.tvheadend43.service with the "ExecStartPost" command as above (and then "systemctl daemon-reload" to set the change) it should add a 10 second delay between Tvheadend starting and Kodi starting. In theory Kodi should be tolerant of the PVR back end being offline, but perhaps there's a racy condition that allows a bug to cause problems or perhaps Tvheadend is up but not fully running and responds badly. Adding the sleep value should force enough time for Tvheadend to come up and settle before Kodi starts and PVRManager tries to connect.