Login at Kodi Home

rmlevit · 2016-02-25, 00:13

I didn't yell and scream. I did calmly report the problem. Was I snarky? Perhaps. But you suggested I should “rm *” from my pictures directory, and you're accusing me of having a crap attitude? I'm not the one that broke Kodi!

**doug** · 2016-02-25, 03:16

(2016-02-25, 00:13)rmlevit Wrote: I didn't yell and scream. I did calmly report the problem. Was I snarky? Perhaps. But you suggested I should “rm *” from my pictures directory, and you're accusing me of having a crap attitude? I'm not the one that broke Kodi!

You're the kind of person with an attitude that pisses off developers. Please stop. They put countless hours into Kodi and users like me really appreciate it. I can only imagine that barrages of posts like yours in the other thread would wear on them.

**scott967** · 2016-02-26, 06:44

There is a ticket on trac #16193 that appears to address this issue. I was able to reproduce this with Kodi 16.0 on Win 7 x64 (Kodi very rapidly committed virtual memory until it exhausted the 4Gb process limit). I don't think PR:7992 is the cause of this problem, just makes it easier to reproduce. When I get a chance will repeat on a Krypton nightly.

scott s.
.

**willemd** · 2016-02-26, 13:05

A while ago I removed a lot of the pictures in the relevant folder, and I think it now no longer crashes in the slideshow.

However, it does crash when I exit the slideshow (i.e. press backspace). Same high memory usage. I guess it's somehow related.

Debug log: http://xbmclogs.com/pyjcgn26u
The crashlog.dmp file is 0 bytes, so no use.

shutterskull · (This post was last modified: 2016-02-27, 22:30 by shutterskull.)

Just to add, I get the same problem. Kodi Jarvis crashes when trying to use recursive slideshow - which previously worked fine on Isengard and all other previous versions.

I get a message - "ERROR: Exception caught on main loop. Exiting." Then Kodi crashes and closes.

How do I roll back to Isengard? Jarvis sucks.

**scott967** · 2016-02-28, 01:23

I did some load testing on Krypton 0227 nightly. What I found was that launching Kodi results in about 230 Mb of Virtual Address Space (VAS) being consumed. I then did some tests by creating a new picture source with varying number of image files (pretty much all are jpg formats) and then running a recursive slideshow on that image source. My results show that the use of VAS is linear with the number of images in the recursive slideshow with a slope of 0.265. Thus the max number of images that can run in a recursive slideshow is about 14,000 before VAS is starved (4 Gb limit) and Kodi crashes. Note that I had "create thumbnail" setting on, but I don't thin the thumbnail gets created until the image file is actually loaded so I don't think that is a factor (I stopped the recursive slideshow immediately after loading it.) I did take a look at actually loading the images to view (not slideshow) and creating the thumbnails did increase VAS usage some (50 Mb or so) but probably wouldn't kill Kodi. I also noticed that exiting MyPictures released that VAS used for thumbnails, while exiting MyPictures after starting a recursive slideshow did not release any VAS (the bulk of VAS was used in the heap).

I did turn on debug to see if there is anything, but no errors or anything interesting get logged, just OnAdd debug entries as the recursive slideshow is being built.

I think that's about as far as I can take this, as I don't have an interactive debugger setup to run Kodi in.

scott s.
.

**willemd** · 2016-03-03, 09:57

I'm wondering if this topic is still in the right subforum. Is this a problem on Linux, Android etc. also?

**da-anda** · 2016-03-03, 10:13

likely all platforms, I'll move it

grmilbrand · 2016-03-22, 19:53

(2016-02-28, 01:23)scott967 Wrote: I did some load testing on Krypton 0227 nightly. What I found was that launching Kodi results in about 230 Mb of Virtual Address Space (VAS) being consumed. I then did some tests by creating a new picture source with varying number of image files (pretty much all are jpg formats) and then running a recursive slideshow on that image source. My results show that the use of VAS is linear with the number of images in the recursive slideshow with a slope of 0.265. Thus the max number of images that can run in a recursive slideshow is about 14,000 before VAS is starved (4 Gb limit) and Kodi crashes. Note that I had "create thumbnail" setting on, but I don't thin the thumbnail gets created until the image file is actually loaded so I don't think that is a factor (I stopped the recursive slideshow immediately after loading it.) I did take a look at actually loading the images to view (not slideshow) and creating the thumbnails did increase VAS usage some (50 Mb or so) but probably wouldn't kill Kodi. I also noticed that exiting MyPictures released that VAS used for thumbnails, while exiting MyPictures after starting a recursive slideshow did not release any VAS (the bulk of VAS was used in the heap).

I did turn on debug to see if there is anything, but no errors or anything interesting get logged, just OnAdd debug entries as the recursive slideshow is being built.

I think that's about as far as I can take this, as I don't have an interactive debugger setup to run Kodi in.

scott s.
.

Thanks for your research on this! seems like very useful info!

grmilbrand · 2016-03-22, 19:54

(2016-03-03, 10:13)da-anda Wrote: likely all platforms, I'll move it

It is all 3 of my platforms: Windows/ShieldTV/Amazon FireTV
Thanks!

amcfarla · 2016-03-25, 06:59

I am having the same issue with doing a random recursive slideshow with a large amount of photos in multiple directories. It used to work fine with Isengard 15 but on 16.1 RC Jarvis, it is crashing on both Openelec and my Nvidia Shield Android TV running 16.1 RC. I have provided a log of the crash, I will note the pictures...well, are NSFW...lol, just so you are aware looking at the log file. I didn't notice any memory issues looking at the screen with debugging turned on. Here is the dropbox link for the crash https://www.dropbox.com/s/c1adhk138ltuc5...d.log?dl=0

MrMC · 2016-03-25, 18:02

known issue, no one seems to care. At some time, when I get a chance, I might poke into it on MrMC fork.

**Martijn** · 2016-03-25, 18:08

Might already be solved by the nuking of cximage in v17.

**Ace** · 2016-03-25, 19:50

No, it is the way how the playlist is constructed. The amount of memory used grows very fast.

grmilbrand · 2016-03-31, 19:35

@MrMC, @Martijn, @Ace, Thank you all for looking into it. Keep up the great work!