Posts by chewitt

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.

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.

Quote from th0maz

Any ideas?

Don't change the NAS name in the first place?

There are lots of different software RAID options. If we add one type for one (small) group of users we'll have to add more types to appease all the other (small) user groups that want something different. Then if we add 'only' the kernel options users will whinge about not having all the userspace tools that are needed to safely use and manage all the different RAID types and use-cases that come with the topic. This compounds the opportunity for complex support issues and increases the software maintenance burden and image bloat (the death of a thousand cuts) for the distro; so the project has always (since early OE days) resisted adding RAID support. Fortunately the distro is open-source with an excellent and simple build-system, and you are welcome to modify it as you like.

No change.

This patch is needed to revert a change that causes glitchy playback and other issues on several platforms https://github.com/chewitt/LibreE…rt-fences.patch

I'm waiting for RPi devs to figure out something with deinterlaced support, then I'll push that patch, a kernel bump to Linux 6.7.0 and few other changes up to the master branch. I forget whether the files currently in my test share have that fix included, or also include something that stops deinterlaced media playback from working .. you're welcome to experiment:

Index of /testing/

It's more time-consuming than complicated. Start with building an Ubuntu 22.04 VM and getting an initial image built.

Two suggestions:

Test again with an LE12 nightly image to see if the issue exists with Kodi 21 (Omega). I'm not expecting there to be a major change between K20 and K21, but it's important to know as development is now focussed on K21 (and will soon shift to K22).

If the issue does exist in K21 it needs to be reported to Kodi developers via the Kodi forum as changes to the DLNA code are not something that LE devs have created; all we do is bundle upstream Kodi into a convenient distro image.