Posts by chewitt

Attempting to support a range of nVidia card generations is a complete clusterfcuk due to different drivers and their wildly different and incompatible dependencies. The latest generations over cards are starting to converge on the open-source standards used with Intel/AMD; and that's likely to force a decision to support only those cards. I've been experimenting with nouveau, but I keep finding issues which appear to be long-running and unresolved so I'm not seeing that as a good and reliable solution.

The /storage/logfiles directory is not a persistent log storage location. It maps to the \\LIBREELEC\Logfiles Samba share and a zip archive of logs will be auto-generated when the Samba share is accessed over the network. If you have not accessed the Samba share from the network there will (correctly) be no files in the directory.

Run "journalctl | paste" and share the URL generated so we can see the system log (Kodi debug logs are unlikely to be useful).

Quote from sufr3ak

I don't think it's Kodi, but possibly hardware related

You're not sharing a Kodi crash log so I have to assume Kodi didn't crash; and the debug log shared doesn't contain anything that stands out. However if as you suggest Kodi is not to blame and it's something lower level causing the issue, that won't ever show in the Kodi log anyway. For that reason you need to share the system log.

It will probably work and be reasonably fast. However your blind guess is as informed as our blind guess, so

Subtitles are broken on Amlogic devices that use a Mali Utgard GPU (all GXBB, GXL and GXM boards) due to changes in OpenGLES shaders that Kodi uses. The developer who made the breaking shader changes (Sarbes) is aware of the issue caused, but he doesn't appear to be doing anything about un-breaking things either.

I assume Allwinner/Rockchip devices are also impacted as some of them also use Utgard GPUs, although I've not seen user reports.

Go back to the oldest LE13 image in the nightly archive and check there. If it does not work, that's good, and you can start to 'bisect' the nightlies (Google what bisecting is if you're not familiar with the concept) to pinpoint the first-good image. We can then look at the changes made on/around that image date to see what might be required for LE12.

If the oldest LE13 image works, the changeset between LE12 and LE13 is too large to guess what the fix was so the solution will be to use the working LE13 image and you need to nag add-on developers to port their add-ons to K22.

You've posted an incomplete Kodi debug log (that doesn't show anything) and no system log. In short; nothing to comment on.

In short, no, because it should be implemented in Kodi and not handled locally for LE. It's been half-investigated by Kwiboo in the past, see https://github.com/xbmc/xbmc/pull/14358, but that PR includes a pile of other things that were a little ahead of the kernel DRM framework maturing and it was closed.

If you want to make a feature request, it should be done in the Kodi forum as this would be a Kodi feature.

video=HDMI-A-1:1920x1080@60D,rotate=90

Kodi does not currently support Linux DRM rotatation so you can configure things like this ^ in kernel boot params (syslinux.cfg) but this is interpreted by Kodi as a resolution change from 16:9 to 9:16 not a rotation. If you also patch Kodi sources like this: https://github.com/xbmc/xbmc/issu…ment-1694808244 it's possible to force a permanent rotation in Kodi too, but that requires you to build a custom LE image (not that hard, but not something everyone can tackle).

Copying xrandr from another image won't achieve anything because the 'x' in xrandr is for X11 and the Generic no longer uses X11 Windowing. The Generic-Legacy image still does, so you can cross-grade to that. The legacy image will still exist for LE13 but I won't guarantee it exists for LE14 .. the demise of X11 is long overdue.

You can also see if an LE12 nightly solves the problem?

Take a backup (in case you want to restore) then update to the current LE13 nightly and test again. Still an issue?

Run "pastecrash" from the SSH console and share the URL

If you grab the relevant Linux, Kodi, and FFmpeg patches (which are probably in jernej GitHub repo; he's one of the Allwinner kernel developers) you should be able to (re)compile things for another distro. There's no HOWTO guide for that kind of thing though, so it'll be down to your tinkering skills.

You need to paste the crash log that demonstrates the play + ffwd/rew + segfault event, not the clean post-crash log that doesn't contain anything useful.

If ffmpeg fails to decode the stream the issue is most likely with ffmpeg support for VAAPI or the Intel GPU driver which provides VAAPI (or an edge case with mesa) so I would start by reproducing the issue on a general purpose distro (in part to prove it's not LE specific) and then report the problem to ffmpeg developers via their 'trac' reporting tool.

Ensure the internal Intel GPU is disabled in the BIOS so only the nVidia card is used, remove the EDID changes from syslinux.cfg, and then use the "Generic-Legacy" image for nVidia GPU support.

NB: Future support is not guaranteed. LE13 dropped the 340.xx nVidia driver this GPU requires as it's not compatible with the latest X11 releases and we haven't yet decided on adding the nouveau driver to the "Generic" image. Even if we do add nouveau, there will be no VDPAU hardware acceleration as this depends on X11.

EDIT: Do not use the LE13 nightly as Da Flex advised because (as noted above) this does not support your GPU any more.

On an ARM SoC device the GPU is used for 2D/3D rendering (GUI) only and hardware acceleration (codecs) are separate things. As Panfrost supports the GPU hardware the GUI works, while decoding requires specific drivers that need adapting to silicon changes with each new chip. The latter are always non-trivial effort and the gene pool of people with the skillsets for the task is tiny; and most of them are commercial developers not the folks working pro-bono that everything normally depends upon. As such the process is slow .. and support probably doesn't exist yet. Over SSH use 'kodi-remote' to press 'o' on the keyboard to bring up the OSD that shows whether you are using (SW) or (HW) decode; but we already know the answer to that.

It's 4K UHD H265 10-bit media that appears to have some kind of DV profile embedded. I can't see anything wrong with the media, but there are numerous things wrong with the current (unfinished since Q1/2020) H265 hardware decoder. At this stage if it works for you that's great. If it doesn't work, there's really nothing we can do, unless you have $250k spare to finance some commercial development to resume/resurrect codec development.