Posts by chewitt

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.

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 VP9@59.94 for most media.

jim_p there are also driver bumps for RTL8189ES/FS that might prevent the warning splats in dmesg? - please test.

Use an LE12 nightly. Put Kodi in debug mode. Reboot. SSH in and run "pastekodi" and share the URL generated.

Older NUCs only support CEC wake; hence the other options are missing. It does HEVC/H264 so should be generally useable, though not sure about VP9. Adding CEC can be done with the Pulse8 adapter if they still exist or can be found at a reasonable price. I'd also look at learning remotes that replace the stock TV remote (nb: these days most TV remotes can learn too).

LE support for Rockchip hardware is mostly aimed at SBC boards. There is an image for a "Hugsun X99 box" but I wouldn't assume that anything found on Aliexpress is 100% the same (there are lots of clones) so it might work, or it might not. Rockchip support mostly depends on upstream activity too. RPi5 is lacking native emmc (although add-on HATs are appearing for that now) and VP9 but is the gold standard for LE software support, and it seems to handle 4K/VP9 up-to 30fps (not 59.94) in software fine. At the current time 4K GUI is not recommended on ARM boards (and most Intel H/W) even the HDMI output is technically capable as all Kodi skins are 1080p and the TV almost always does a better job of upscaling 1080p to 4K than Kodi does (Kodi needs to do it in software and this will noticeably slow down the GUI. CE probably has options but their approach to open-source software seems to involve not-always providing sources and deliberately using pre-compiled blobs; most users don't care, some find that distasteful and look for something else. I don't run it so cannot recommend it.

If the 4K/UHD rips you make are HEVC then the RPi4 should handle them fine, and is free since you already have it. RPi5 is faster in GUI nav and a few other things but that's spending $$. I haven't used Intel hardware in years so can't make a recommendation on that side (RPi5 is the daily-driver).

Quote from racemaniac

What is now the next step for this issue?
Will your fix get merged into the main libreelec repo? Or will people with newer intel cpus be dependent on your fork?

It's a workaround not a fix, so further investigation is needed to identify and resolve the root cause. Links to the Intel DRM issue tracker were posted already. The Intel devs that you need to contact are probably lurking in the #alsa-dev IRC channel on Libera and/or the #linux-media channel on OFTC too; but start with formally recording the issue on the tracker.

What happens if you complete the Wizard in English, then reboot, then change Kodi to German language after reboot?

Cron normally requires the full path to a binary, so "/usr/bin/dd" instead of plain "dd" but the rest should work. You might want to log output to somewhere on /storage to ensure it works fine.

Quote from DeltaMikeCharlie

Check to see that Kodi addons ‘service.tvheadend42’ and ‘pvr.hts’ are installed and enabled

Just be advised that the moment there's upstream movement on a TVH 4.4 release we will be dropping the TVH 4.2 add-on (as 4.2 will no longer be the 'stable' TVH release). It would be better to develop against the 4.3 add-on.

SD card issues appear to be resolved, but I haven't pushed the changes to the main LE repo yet; hence not in nightlies. I'm using a newer kernel than the rest of LE and some breakage in shitty Realtek drivers need to be resolved before I can push the Linux 6.7.0 kernel bump to the main repo. NB: We don't need "testers" we need people that write kernel drivers

The settings add-on provides a backup/restore function not a backup/migrate function so "everything is working as expected" from our perspective. You need to clean install on the RPi5 then copy the .tar file to the device, unpack it, stop Kodi, then selectively move the bits you care about to their required locations and restart. You may find that you need to create/setup a passwords.xml file to go with sources.xml if you updated from a much older release. Otherwise things should work. In library views the /path/to/file detail is only shown under the "refresh" icon.