[umbongo]

Hello 

I think I'm seeing a memory leak in Kodi v18.6?

I have AeonMQ8 skin installed and sitting on Settings where you can see the Memory Usage. When my machine is recently rebooted, it says Memory Usage at 9%. Gradually after watching media and leaving the system on this number increases. It does this to the point where I can't play any media easily or stop it, without the system generally hanging or becoming unresponsive for a long period of time when the screen changes. I can pkill -9 the kodi application but then I invariably have to reboot the system as well. It's quite frustrating. 

I'm happy to follow and logging instructions to demonstrate the issue, if you have them please. Thank you for your help!

Ubuntu: 18.04LTS Kernel 5.3
Intel NUC8i3BEH

[Klojum]

The AeonMQ8 skin is a pretty "heavy" skin with plenty of additional functionality.

Did you have the same mem leak when using Kodi's default Estuary skin?

[umbongo]

The AeonMQ8 skin is a pretty "heavy" skin with plenty of additional functionality.

Did you have the same mem leak when using Kodi's default Estuary skin?

Hmmmm... not sure. I'll definitely try it and report back!

I'm also running the AeonMQ8 on a newly built (today) RPi4 (4GB). I'll monitor that too to see if it sees the same issue.

[umbongo]

The AeonMQ8 skin is a pretty "heavy" skin with plenty of additional functionality.

Did you have the same mem leak when using Kodi's default Estuary skin?

I've changed the skin to Estuary, which doesn't present the Memory Usage as friendly or as readily as it does in the AeonMQ8 skin. 

Certainly there is an issue when changing resolutions. 
I have my Ubuntu Gnome desktop resolution set to its native 3840x2160, and Kodi Estuary 18.6 set to the same. If I play media which is 1920x1080 or 1280x720 (I've whitelisted all available frame rates and interlacing options), then there are notable periods of black screen when I press play or stop playback. These last for like 5 to 10 seconds, making the user experience clunky and unenjoyable. This black switching process seems to get worse the longer the system uptime. 

I've tried changing the "delay after change in resolution" option, setting this to Off and to 10seconds, but this doesn't help with the above. 

So to me, it seems like Kodi 18.6 has a problem with 4K resolutions? 
I have been using Kodi for many years, previously with my 1080p Television and never had an issue watching videos at different resolutions. I've always used an AeonMQ skin, especially now since it's a straightforward option with v18 Leia. 

(One other bit of info. I have a RPi4(4GB) running with at 1080p Television (my old one) and AeonMQ8. It plays all media fine, and the memory usage doesn't increase. 
If I attach it to my 4K Sony Bravia Television, I can't play ANY media smoothly, despite whitelisting all available resolutions... the media always stutters on motion playback. This happens with the Estuary skin as well). 

Any thoughts or help please?

[umbongo]

just an update: 

the system has been up 2 days 6 hours and the system memory usage is now up to 38% (was 9% after boot). Also, the interface is idling on 1920x1080 after watching an HD show, when the resolution of the interface has previously been set to 3840x2160....

[umbongo]

I then try to quit kodi (sudo pkill -9 kodi, or quit it through htop)... the interface is now static on the screen and I cannot get back to the desktop without rebooting the machine.

[umbongo]

literally running virtually only Kodi and the memory leak continues. 

Any advice?

[smp1]

This must be something OS-related. There is no such issue in LibreELEC.

[black_eagle]

Hmmm, are you just going by the memory usage that Kodi is telling you ?  What does top say about it ?

For instance, V19 has been running on my machine for nearly 3 days now and Kodi reports 42% for system memory usage.  However, top reports only 6.3%


   VIRT       RES       SHR
3838688 899648  83940

So what those three figures are.  Virt is the total virtual size of the process (this is likely the figure Kodi is reporting) and it is the sum of the actual memory Kodi is using, plus memory it has mapped into itself (eg the video cards ram for the X-server), files on disk mapped into it (including shared libraries) and memory shared with other processes.

Res is resident size, it corresponds to the MEM column in top and is how much physical memory the process is using.

Shr is how much of the virt size is actually shareable (memory or libraries). In the case of libraries, it does not necessarily mean that the entire library is resident. For example, if a program only uses a few functions in a library, the whole library is mapped and will be counted in VIRT and SHR, but only the parts of the library file containing the functions being used will actually be loaded in and be counted under RES.

Free memory is not something you want a lot of. If your system has been up for a long time and has a lot of free memory something is wrong. If you have a memory leak, you will see free memory and buffers both begin to shrink. This is still not a severe problem, as the leaked memory should eventually be moved to swap space. Your system will still run fine until you fill the swap space, and draw down the remaining free space to the point programs can't be started.

With regard to not getting back to the desktop.  I can't remember when it started exactly, but I do know that if I force-quit Kodi, it leaves the GUI on the screen.  As I run it on a TV in a separate X-Screen it's not an issue for me and I have never bothered investigating why. I just presumed it was something to do with X.  However, I also found when upgrading from 16.04 to 18.04 that I lost the ability to easily show the desktop.  I could alt-tab to the desktop in Unity, but not in Gnome.  So I mapped alt+ctrl+d to show it.  Might be worth trying that and seeing if you can get back to your desktop that way.

[umbongo]

Hi, thanks for your detailed response. 

I have an update to report. I bought the following device: 
https://www.amazon.co.uk/gp/product/B072...UTF8&psc=1

This device sits between my Intel NUC and between the 4k Bravia TV. It emulates a 1080p EDID handshake coming from the TV, telling the Intel NUC that the maximum it can output is 1080p. It also fools the Intel NUC into thinking the TV is always on. 

I have noticed when using it, the Memory counter in Kodi never goes beyond 15%, no matter how long the system uptime. Watching videos of different resolutions / raster sizes, the Kodi GUI is always very responsive, and immediately switches between the two. 

So it seems without it, the Intel NUC loses the EDID handshake with the TV after the TV is put into standby, and waking the TV somehow requires use of more RAM by the Intel NUC (to the point where Kodi becomes virtually unresponsive). 

I also bought the following: 
https://tmfsolutions.co.uk/product/hdfury-dr-hdmi-4k/

This is supposed to do a similar thing, but in 4K, especially with its HTPC mode designed to trick the computer into thinking the TV is always on. However I have found it doesn't work as well as the other 1080p device mentioned above (I'm going to look for a 4k version of one on Amazon, I remember seeing one a while back). 

So this seems to be the resolution for my immediate problem, for now. I hope it can help other users. All the best.

[fritsch]

That's an interesting find.

[satadru]

Hi, thanks for your detailed response. 

I have an update to report. I bought the following device: 
https://www.amazon.co.uk/gp/product/B072...UTF8&psc=1

This device sits between my Intel NUC and between the 4k Bravia TV. It emulates a 1080p EDID handshake coming from the TV, telling the Intel NUC that the maximum it can output is 1080p. It also fools the Intel NUC into thinking the TV is always on. 

I have noticed when using it, the Memory counter in Kodi never goes beyond 15%, no matter how long the system uptime. Watching videos of different resolutions / raster sizes, the Kodi GUI is always very responsive, and immediately switches between the two. 

So it seems without it, the Intel NUC loses the EDID handshake with the TV after the TV is put into standby, and waking the TV somehow requires use of more RAM by the Intel NUC (to the point where Kodi becomes virtually unresponsive). 

I also bought the following: 
https://tmfsolutions.co.uk/product/hdfury-dr-hdmi-4k/

This is supposed to do a similar thing, but in 4K, especially with its HTPC mode designed to trick the computer into thinking the TV is always on. However I have found it doesn't work as well as the other 1080p device mentioned above (I'm going to look for a 4k version of one on Amazon, I remember seeing one a while back). 

So this seems to be the resolution for my immediate problem, for now. I hope it can help other users. All the best.

For what it is worth, I have my edid info from my tv dumped to to /lib/firmwared/edid/edid.bin. I then have it loaded at boot by the kernel. Maybe that might work better than using an external device? (I'm using the intel gpu on a skylake system with focal 20.04 & kodi via the Kodi stable ppa.)

In /etc/default/grub I have this section in the GRUB_CMDLINE_LINUX line: drm.edid_firmware=HDMI-A-1:edid/edid.bin"

I also made sure the edid data was loaded in my initramfs at boot thus:

/etc/initramfs-tools/hooks/include-edid-data

#!/bin/sh

PREREQ="udev"
prereqs()
{
   echo "$PREREQ"
}

case $1 in
prereqs)
   prereqs
   exit 0
   ;;
esac

. /usr/share/initramfs-tools/hook-functions
# Begin real processing below this line

if [ ! -e "${DESTDIR}/lib/firmware/edid" ]; then
    mkdir -p "${DESTDIR}/lib/firmware/edid"
fi

if [ -r "/lib/firmware/edid/edid.bin" ]; then
   cp /lib/firmware/edid/*.bin "${DESTDIR}/lib/firmware/edid/"
fi

manual_add_modules i915
exit 0