Posts by chewitt
-
-
Code
Display More# 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

-
Please provide a full debug log.How to post a log (wiki)1. Enable debugging in Settings>System Settings>Logging2. Restart Kodi3. Replicate the problem4. Generate a log URL (do not post/upload logs to the forum)
use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link -
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.
-
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.
-
-
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.
-
Code
Display More[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.targetKodi 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.
-
Nightly builds are here: https://test.libreelec.tv and the images are quite stable to use (whatever you're using at the moment isn't working either, so we're unlikely to make anything worse). I'm asking for logs for two reasons: a) we don't know what hardware you have and pastekodi content will reveal that, b) if there are problems where things don't start, there are normally useful contents in debug logs that hint to the problem. The info you've shared so far isn't enough to diagnose the issue.
-
I pushed an update to my test share which includes a fix for 4K VP9 @ 59.94/60 content on GXL/GXM (and newer) boards. Previously dmesg would show an invalid clock rate error and HDMI sync would be lost until playback was cancelled. That should help YouTube playback as the 4K default seems to be [email protected] for most media.
jim_p there are also driver bumps for RTL8189ES/FS that might prevent the warning splats in dmesg? - please test.
-
Please provide a full debug log.How to post a log (wiki)1. Enable debugging in Settings>System Settings>Logging2. Restart Kodi3. Replicate the problem4. Generate a log URL (do not post/upload logs to the forum)
use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link