"Out of memory" error after short run time

[ember1205]

I am trying to use high quality images that I have shot and edited. All images are in a local directory and in JPG format. Sizes range from about 1.7MB to close to 12MB for each image.

I'm running on a RPi3 w/ 1GB RAM. Configuration is:

{ module: 'MMM-BackgroundSlideshow', position: 'fullscreen_below', config: { imagePaths: ['modules/MMM-BackgroundSlideshow/images/'], transitionImages: true, validImageFileExtensions: 'bmp,jpg,gif,png,JPEG', backgroundSize: 'contain', randomizeImageOrder: true } },

I start up MM and after only a short amount of run time, it will completely crash with the following error in the log:

[2219:1212/085505.692849:FATAL:memory.cc(22)] Out of memory. size=96641024

The error appears to always be the same, the image that is displayed when it crashes is not always the same.

[hesspet]

I run into the same problem. Error message is similar. If I use smaller images, time to crash is longer. The bigger the images, the faster the crash. I removed BackgroundSlideshow from config.js. MM runs stable over the day. Start the Slideshow and change pictures every 30 seconds with transitions.

There is one thing I've seen, the problems occurs more when I use a more images. I've made one thest with 20 Images and max size aprox. 2.5 MB. This was the only setup which runs longer. But also with a high memory consumption close to the edge.

[hesspet]

Next day: I think I can idenify the problem: Im made some additional tests.

1. one directory with files perfect sized to the size of my monitor 1920x1080. 20 files. Started this before going to bed. Works properly the next day.
2. one directory with large files I had in my directory. Big sized 5000x3000 an similar. Jpegs with 20 MB and more. Fire MM and you can see the memory increases each time a picture is loaded. Often the footprint of the images seems to be more than 70mb in memory. After a while the memory is totally used and the modul dies. At this momemt the memory is freed.

So what's happening?

Theory starts here :-)

One of the main "problem" is in this lines: (It is not a bug, see in the text!)

getDom: function() { var wrapper = document.createElement('div'); this.div1 = this.createDiv('big1'); this.div2 = this.createDiv('big2'); So what's happening here?

The images are loaded into this divs later on. For each image one of the divs is reloaded. But those variables are not bound to root (they are bound to the module object), so the garbage collector does not remove the used memory fast. The GC must do a deep scan to free the no more used memory. The memory of the image.src..... So at some point, wie have maybe more than two images with a huge footprint in memory. If we have fast reloading times, the GC does not have enough time to find the unused memory and the memory usage increases until the memory is fullfilled.

I can see this effect, if I make the transition not every 40 seconds. I made a 3rd test with a image changing after 10 minutes and in this case the memory is freed after 2 or 3 minutes after the next image was loaded and the module runs better. (needs some additional tests)

Workaround: Don't use big sized images (bigger than "contains" maximum size) and give the browser time to run the GC.

This works for me.

Can we fix it? I'm totally new to MM and I have no idea how to force the GC inside this environment. I had a similar problem in a webapplication some years before. In this project we used the workaround I showed with success. Each picture which is inserted into the filesystem and is to large was srinked with imagemagic, so it is no more the job of the browser to handle the size. This solution works for me, but I'll do some more tests during the next days with many more images.

BTW: sorry for my poor english, but I tried to explain whats happening (in my point of view).

[ember1205]

MMM-ImagesPhotos is sort of a "fork" of this module. While it, too, experiences the same exact crash, it is MUCH less frequent and much more random. I have had it run for a few days with zero issues and I have had it crash repeatedly within a few hours.

I theorized for both modules that larger images were essentially to blame, but the author of the forked module claims to have zero issues with his and he NOT conforming the photos or shrinking their size like you suggest.

There is definitely something odd going on, but I can't seem to directly correlate it to an actual issue of not having enough memory as there is still free memory in the system leading up to the crash.

[hesspet]

After shrinking the image sizes, the error never occured again. I tested the MMM-ImagesPhotos. The problem occurs the same on my machine. My Raspi is a little bit critical on this, cause I removed the swap-file :-) and there is only 200 MB Memory headroom after starting MM and some other tasks.

[hesspet]

MMM-ImagesPhotos is sort of a "fork" of this module. While it, too, experiences the same exact crash, it is MUCH less frequent and much more random. I have had it run for a few days with zero issues and I have had it crash repeatedly within a few hours.

I theorized for both modules that larger images were essentially to blame, but the author of the forked module claims to have zero issues with his and he NOT conforming the photos or shrinking their size like you suggest.

There is definitely something odd going on, but I can't seem to directly correlate it to an actual issue of not having enough memory as there is still free memory in the system leading up to the crash.

It's only a matter of changing speed.

[mcnahum]

so the default value of 10s is crazy ... and should be more 10 min ...

[ember1205]

Huh? What default value?

[milkywade]

anyone found how to get rid of this issue? It does not seem to me that reducing the update frequency or the number of images would be an acceptable solution

[mihsav]

Hello guys I'm having the same Problem, after a random period of time it seems that the MM is running out of memory. If I disable this module the MM will work perfectly fine. Is there something you can do about it, I really like this Module but right now is impossible to use it anymore. Thanks

[hesspet]

As I wrote before, the only workaround I see is reducing die size of the images to the needed size of the monitor. I've done this in January and since this time my MM runs flawless. Uptime now more than 50 days! I change the pictures every minute! 24h a day. I'm running now 3 instances at home, office and for my daughter. No flaws.

If the plugin must shrink the images it needs more than 2 times the size of the full image (not the jpeg file size). So 100 or more MB of memory are used during the convertion. This is too much for a small Pi due to the hight memory consumption of the MM instance itself. If the image has the correct size, no convertion must be done and everythings works smooth and fine.

BTW: I see no way to fix this problem if we use the Chrominum functions under the hood.

I tried to build a solution with imagemagic as converter. I made a upload directory and the files are converted via imagemagic to the image directory of the plugin via cron. This worked but it is just the workaround and not unter control off MM. Just a hack.
Now (Better): I convert the images offline and upload the shrinked images.

BTW: I've made a test on standard PC with Linux. I used my in the original size (30 MPixel). The total memory consumptions raises a top of 3,5 GB.(Chromium need 80% of this memory)..... then with the reduced images: 700MB.

[mihsav]

Thank you @hesspet , I followed your advice and seems to work well for me too. Is working since then without any problems.