[x86-64] Video playback freezes after about an hour

  • Hey everyone,

    I’ve been using LibreELEC for a few months now, and overall it works great. However, I’m experiencing a strange and persistent issue during video playback.

    My setup:

    • LibreELEC 12.2.1
    • Media streamed from a Synology NAS via SMB
    • Client: Dell Wyse 5060 Thin Client (AMD GX-424 SoC, 6 GB RAM)
    • Network: Wi-Fi (built-in wireless card)

    System resources look fine during playback: roughly 10% RAM usage and about 30% CPU usage.

    The problem occurs after about an hour of playback (sometimes a bit longer). Video playback suddenly stops, audio continues for a few seconds, then stops as well, and Kodi freezes completely. At that point, I have to reboot the system to continue watching.

    SSH remains fully responsive during the freeze, so the OS itself does not hang - only Kodi does.

    In some cases playback stops on its own, but very often the freeze happens when I try to seek forward or backward after long playback (around an hour as well). Seeking almost always triggers the freeze.

    This is the link for the log of the crash:

    External Content pastebin.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Has anyone encountered a similar issue or have any idea what could be causing this?

    Many thanks! 🥰

  • Please provide a full debug log.

    How to post a log (wiki)

    1. Enable debugging in Settings>System Settings>Logging
    2. Restart Kodi
    3. Replicate the problem
    4. 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
  • Thanks for the fast answer! Here is the created log: https://paste.libreelec.tv/measured-wildcat.log

    I caused the crash manually by seeking forward after about 1 hour and 10 minutes.

    One thing worth mentioning is that I watched another movie before this session, and it played without any issues. It turned out hardware acceleration was turned off and the Adjust Display Refresh Rate setting was set to Always. (I was messing with these settings before.) So I am suspecting a hardware decoding issue or something about the refresh rate. After turning on HW acceleration and turning off Adjust Display Refresh Rate, I could reproduce the issue.

  • Code
    radeon.si_support=0 amdgpu.si_support=1

    Some ChatGPT analysis of the kernel splats in the log suggests Kodi triggers a GPU driver bug. It also claims there are long-running issues with the (newer) radeon driver on old(er) hardware. It does also suggest disabling HW decoding to see if that code-patch is involved. And from your comment, it appears it is. I have no real knowledge of AMD hardware but it suggests seeing if the older amdgpu driver works better than radeon? .. which is achieved by adding the above ^ to the kernel boot params in the EFI boot config (as you are EFI booting and not using Syslinux). You can edit that from SSH by doing mount -o remount,rw /flash and then editing the file, then rebooting. If it doesn't work out things might crash or not display but you should still be able to SSH back in and revert the change made.

  • So I did the changes chewitt recommended and also did a whole lot of testing but unfortunately I have no success yet. I could cause a crash again. Here is the log for the amdgpu drivers: https://paste.libreelec.tv/stirred-mustang.log

    What is not completely clear to me is that when Kodi crashes I get errors like:

    Code
    Jan 30 18:10:20.405573 Wyse kernel: radeon 0000:00:01.0: ring 0 stalled for more than 10164msec
    Jan 30 18:10:20.406390 Wyse kernel: radeon 0000:00:01.0: GPU lockup (current fence id 0x0000000000037021 last fence id 0x0000000000037023 on ring 0)

    It indicates that the radeon driver is still in use, or isn't it?

    Also I have tested different scenarios:

    1. HW decoding (original setup) and Adjust Display Refresh Rate is off: causes a crash. It was the basic issue.

    2. HW decoding and Adjust Display Refresh Rate is set to always: seems okay.

    3. SW decoding and Adjust Display Refresh Rate is off: seems okay too.

    4. HW decoding (amdgpu drivers (?)) and Adjust Display Refresh Rate is off: causes a crash.

    So yeah, I don't know what is the cause of the issue. The 2. setting could work, but the problem is that I have a pretty basic television and if Adjust Display Refresh Rate is on, it forces the TV to do some resampling and the image quality becomes horrible. For this reason this must be off.

    Or should I just let HW decoding go and use SW instead?

  • ChatGPT analysed the splats and suggested the change, but GoogleAI claims the CPU is 'Sea Islands' and not 'Southern Islands' and according to https://wiki.archlinux.org/title/AMDGPU this needs a different config. This would explain why it doesn't appear to have switched drivers.

    So see if changing to radeon.cik_support=0 amdgpu.cik_support=1 makes a difference? - I would also disable SMB component debug logging as this only adds to system load. Also experiment with 'start/stop' option for adjust-refresh, as this is a little less aggressive at syncing. This article is not just for 4K/HDR and has suggestions https://wiki.libreelec.tv/configuration/4k-hdr