Login at Kodi Home

hoppel118 · 2016-08-16, 10:58

Hi guys,

I also have this issue on my odroid c2 with libreelec 7.0.2. I recognized that I don't have this issue with kodi 16.1 for windows. When the windows kodi reaches the last remaining 10% (round about 400MB of 4GB in my case) of the machines ram, it ends filling the ram.

Can you confirm this? If so, where is the difference in the windows version of kodi?

@the_bo Thanks for drawing my attention to this thread.

Greetings Hoppel

wrxtasy · (This post was last modified: 2016-08-16, 16:33 by wrxtasy.)

Same problem also with LibreELEC Jarvis on the Hub:

http://wetekforums.com/v/index.php?p=/di...-using-pkc

loggio · (This post was last modified: 2016-08-17, 13:37 by loggio.)

I get this massively on milhouse nightlies running titan.

For example
Using PVR with Titan skin:
Enter the channels window click a channel to play, enter Fullscreen video... Press 'back' the video is "windowed" and is shown in a preview box and the entire screen becomes incredibly laggy and struggles big time slowing the pi right down ...
If I exit pvr channels window, the video is then playing in the background and it not as laggy.

This never happened in kodi 16 libreelec builds using Titan skin and mmal.
I was always able to set "Limit gui updates during playback" to 'unlimited' and never suffered any lag when browsing kodi while video was playing back.

If I use OMX Player then it all goes away, but I don't like omx player... It causes all sorts of issues with audio sync on my setup.

**popcornmix** · 2016-08-17, 16:00

Yes, there is a bug where textures are not freed when playing video in background.
See: https://github.com/xbmc/xbmc/pull/10305

the_bo · 2016-08-17, 16:46

(2016-08-17, 16:00)popcornmix Wrote: Yes, there is a bug where textures are not freed when playing video in background.
See: https://github.com/xbmc/xbmc/pull/10305

Thanks @popcornmix for looking into it Smile

wyrm · 2016-08-17, 16:55

Popcornmix,

I suggest you might want to give this a look as well as Marcel and I tracked this down at one point while trying to figure out why memory was not being freed while scrolling thru our respective skins.

216729 (thread)

Short story: if a skin is making use of hidden animation types, memory for images does not get released. To a large degree I got around the problem by dropping hidden type animations. Unfortunately, cover flow view types require this type of animation to function, so still a problem as far as I can see.

Wyrm (AppTV)

**popcornmix** · 2016-08-17, 17:08

I could make the change I believe you suggested (change !IsVisibleFromSkin to IsVisibleFromSkin) which makes some logical sense to me,
and it will appear in the next Milhouse build.

Will you be able to confirm the problem is fixed? If so (and others don't report new issues) I can try making a pull request.

wyrm · 2016-08-17, 17:21

(2016-08-17, 17:08)popcornmix Wrote: I could make the change I believe you suggested (change !IsVisibleFromSkin to IsVisibleFromSkin) which makes some logical sense to me,
and it will appear in the next Milhouse build.

Will you be able to confirm the problem is fixed? If so (and others don't report new issues) I can try making a pull request.

popcornmix,

Sorry mate, can't really help there as I'm still coding my skin for Jarvis (don't make the jump to a new release until at least beta drops due to breakages caused by API changes in alphas).

Just spotted your pull request on github and thought that Marcel's and my investigation of previous problem seemed relavant. Should imaging the bleeding edge crowd should spot a difference one way or another pretty quickly as removing the animations seem to make a large difference. And for the record, yes your solution was what I thought should be happening.

Wyrm

**popcornmix** · 2016-08-18, 01:16

Latest Milhouse build fixes the texture leak when playing video in the background.
Also includes the hidden animation change. If anyone who experiences the issue can test that would be useful.

hoppel118 · (This post was last modified: 2016-08-18, 10:13 by hoppel118.)

@popcornmix: Thank you for investigating your time. I really appreciate this.

@wrxtasy: Do you see any chance that this fix gets ported to your libreelec 7.1 for the odroid c2?

Thanks to all!

Greetings Hoppel

the_bo · (This post was last modified: 2016-08-18, 14:48 by the_bo.)

Thanks @popcornmix. Really appreciate the gpu mem fix ill give it a test.

Will the hidden animation change affect the layout of skins in anyway?

cheers

**popcornmix** · 2016-08-18, 15:30

(2016-08-18, 14:43)the_bo Wrote: Will the hidden animation change affect the layout of skins in anyway?

I don't believe so. Please report if there is any change.

wrxtasy · 2016-08-18, 16:29

I have a C2 LE Jarvis test version over in the C2 hardware thread for @hoppel118 and @the_bo to test with the two backported Popcornmix patches.

Thx PCM.

I loaded up a reasonably large video library with lots of textures and started background video, then went Library browsing.
Free RAM did decrease as expected and then slowly increased again when I stopped browsing.
Is this what we are looking for ?

Using the Skin Eminence 2.0, with a few Animations as well.

@hoppel118 and @the_bo, please reports any findings back in this thread.

wyrm · 2016-08-18, 17:42

(2016-08-18, 16:29)wrxtasy Wrote: I loaded up a reasonably large video library with lots of textures and started background video, then went Library browsing.
Free RAM did decrease as expected and then slowly increased again when I stopped browsing.
Is this what we are looking for ?

wrxtasy,

From what Marcel and I saw when we first spotted the issue, yes that sound right. In our cases we were using hidden type animations for background fanart display. Removing the hidden type animation saved about 40-50M of ram (which on a AppleTV gen2 or a Raspberry Pi 1 was a significant amount of memory). It would really depend a lot on how the skin writer has coded the skin. Also if the animation is used on icons and other smallish Image files the savings would be quite a bit less, but probably still worthwhile.

Basically without the patch the memory is eventually released (when you leave the video library screen), with the patch a short time after the image is no longer on screen it is released. So if the list is moving there will be a number of images still in memory that are no longer required but have not had enough time to be released (free memory going down). Stop the scroll and the system catches up and releases the memory (free memory goes up).

Should make NO difference to the skin, but should be a bit lighter on the memory. But as always, your mileage will vary depending on what skin you are using.

Wyrm (AppTV)

hoppel118 · (This post was last modified: 2016-08-18, 18:45 by hoppel118.)

(2016-08-18, 16:29)wrxtasy Wrote: I loaded up a reasonably large video library with lots of textures and started background video, then went Library browsing.
Free RAM did decrease as expected and then slowly increased again when I stopped browsing.
Is this what we are looking for ?

Using the Skin Eminence 2.0, with a few Animations as well.

@hoppel118 and @the_bo, please reports any findings back in this thread.

Hi @wrxtasy: Thanks in advance for porting the Popcornmix's fix that fast to the oroid c2 libreelec. The Update worked like a charme. I only put the tar file to the update folder, rebooted, the update started automatically, next reboot also automatically, ready. The memory leak problem is solved for my use case. Great work!

I came from libreelec 7.0.2. It was my first libreelec update this way.

@Popcornmix: Thanks again! Wink

EDIT: By the way, I use the skin "aeon nox silvo".

Greetings Hoppel