[x86_64] playback ui not smooth since build 13.0-nightly-20260517-7374d38 on amdgpu

  • As the title says, opening the playback ui (hitting enter) or the playback info (pressing o) is not smooth and causes massive frame drops on a system with an AMD GPU since build 13.0-nightly-20260517-7374d38. The last working build is 13.0-nightly-20260516-ba37c30.

    My system:

    Ryzen 5 5600x | 16Gb Ram | RX 6600 | 16Gb Optane M10 boot disk


    First, I thought it was due to a Kodi change, so I compiled myself different versions of LE with different Kodi commits from May 16 and 17 with the latest set of LE patches.

    All showed the same behavior. I then compiled the Kodi version (c685f9c0efe9439f16018d450a78aa7ed25c2b8a) that comes with the last working build on top of the latest LE patches. I expected perfect results, as I thought it must be a Kodi issue... but also with that build, I also experienced the mentioned issue. So, no Kodi issue but a LE one?

    I checked the commit history on what has changed between May 16 and May 17. The most obvious was the inclusion of NVIDIA GBM drivers. (which also made the image size 200mb bigger)

    So I compiled a version with the latest Kodi and with nvidia-ng removed from the "GRAPHIC_DRIVERS=" OpenGLES option, and now it's smooth again. I don't know why excluding drivers that aren't even loaded fixes the issue... Or are they loaded??


    I also added the logs from the official LE builds

  • Please retest with the Generic image here: https://chewitt.libreelec.tv/testing/ .. it has some additional changes.

    I noticed this too on my AMD machine. While playing. When you open say the menu that has the stream information “O” the video doesn’t skip frames. It actually just completely pauses until the menu is open.

    I tried your latest build which works great except this issue.

    I’ll try one of my N150 here later today.

  • Do I understand correctly - if on current LE master you remove nvidia-ng from options then it works ok?

    Yes, exactly.

    No frame skips when GUI is opened.

    Once opened, everything is fine. The "opening" process causes a massive frame drop.


    Here is my (working) build with nvidia-ng removed...

    <download removed, no longer needed>


    I will try the "Generic image" from Chewitt.

    Edited once, last by mitzsch (June 3, 2026 at 1:43 PM).

  • I've managed to identify the culprit, it's our custom gputemp script which gets called whenever you open the player process info overlay or the system info window.

    I've created a PR with the fix:

    Generic: gputemp: use nvidia-smi only if an Nvidia card is present by HiassofT · Pull Request #11414 · LibreELEC/LibreELEC.tv
    Running nvidia-smi on a non-nvidia system causes a long delay as nvidia-smi will try to load the nvidia kernel driver if it's not present.
    github.com

    so long,

    Hias

  • gputemp has vanished on pure Intel since ~2 weeks (System Info => Video)


    while at it

    System Info

    * Summary: it would be nice to see what kernel the box is runnning (delete the word "community" ?)

    * Summary: running an NUC13 with 16T here. Displayed is only thread 0-11 !

    alas I haven't figured who to get this view:

    [GUI] Add alternate CPU usage GUI label by CE-Repo · Pull Request #28311 · xbmc/xbmc
    Description This adds an alternative display for CPU usage Screenshots (if appropriate): Types of change Bug fix (non-breaking change which fixes an…
    github.com
  • ...

    while at it

    System Info

    * Summary: it would be nice to see what kernel the box is runnning (delete the word "community" ?)

    * Summary: running an NUC13 with 16T here. Displayed is only thread 0-11 !

    It's a resolution/font size problem, with long text strings that don't wrap and therefore extend out of the viewport.

    The data fields pulled for that window are an upstream Kodi thing, not something LibreELEC has customised.

    It's one of those ancient "core" things that's been around in more or less the same form since Xbox XBMC days with very minor changes. It calls a fixed label ID which has fixed elements that are mapped to fixed references from strings.po and localisations. (You can't even easily do things like add a simple [CR] to make a new line to 'wrap' the overflow text onto.)

    There are so many builds/forks/skins built on top of that fossilised foundation that would break horribly if changes to that stuff were not managed exceedingly carefully (one reason that pull request you referenced will probably not get anywhere any time soon)

    Given all that ... It would be far, *far*, FAR easier to modify your skin (or UI resolution) so that the long string doesn't go outside the bounds of the display window. :P

    If you want to tinker with the skin method, play with values in:

    SettingsSystemInfo.xml

    (Exemplar values from default Estuary skin)

    Code
        <control type="label" id="x">
            <width>1400</width>
            <font>Mono26</font>

    and

    Code
         <control type="label">
    					<description>CPU Text</description>
    					<width>auto</width>
    					<height>40</height>
    					<label>$LOCALIZE[13271] $INFO[System.CPUUsage]</label>
    					<aligny>center</aligny>
    					<font>font12</font>
  • already on the box

    Thanks


    P.S.

    I'm following the git's, build system

    Question:

    could one (as an external via web) see what last LE-git-commit is currently compiling in the build system ?