EyeCandy and out-of-memory
-
I’ve upgraded to 2.4.1 and using the suggested OpenGL driver and all is well. Decided to play with some new modules and enabled the MMM-EyeCandy and it also worked well… for a while. I found that with a particular image selected (37), it would work, but go a little glitchy - stuttering on animations. And then after something like 10 minutes the screen would freeze. And then a while later it might recover, or it might just switch to a black screen. Weird. With a bit of debug, I found that the electron process that was running the animation would consume all the memory until eventually the OOM killer would kill it. At which point, the X server would just show nothing until magic mirror was restarted. I don’t know if this is a previous known problem with eye candy, a problem with using the OpenGL driver, or 2.4.1 of MM with it’s usage of updated electron.
In terms of logged errors, there’s obviously the oom killer log showing that it killed electron. There are logged errors in the MM logs, but they are from a different electron processes to the one that was running out of memory:
- the unhandled promise rejection errors that others have asked about
- and gles2_cmd_decoder errors.
Both of those errors were from other electron processes to the eyecandy (is there an easy way to associate electron PIDs with MMM modules? I’m using guesswork…)
Anyhow, I’ve disabled the eye candy module for now and everything works fine, but curious as to how to debug this more, or how to protect things better (e.g. can electron provide simple ulimit controls for the subprocesses? Perhaps something for pm2 configuration?)
-
@njw said in EyeCandy and out-of-memory:
I found that with a particular image selected (37)
So, the issue is specific to that selection? I didn’t do long term testing on every image(url). That would have been more time than I was willing to give to this module. Frankly, I’m surprised anyone is even using it. No one has reported any problems with the module, until now, with you.
Let see how things go with the new electron version and the GL drivers. In the meantime, thanks for your interest and accept my apologies for the trouble you’re having, if the module happens to be at fault.
-
I also used eye candy! it’s great! but unfortunately, yeah, it runs up the memory, and in my case crashes the display… I have since commented out the plugin in my config, but that plugin is top shelf man! love it!!
-
@Mykle1 I realize it’s not the most … informative… of modules, but I was playing around with the idea of combining it with face recognition, to show the freakish eye when it’s someone it doesn’t recognize :).
This was with the new electron version and the GL drivers. I had some of the other eye candy URLs on the screen for a day or so, playing around and no issue. However, just that particular selection it would crash in about 10 minutes. Weird. Possibly the memory usage was high on the others - I didn’t do any debug until it broke, of course.
I’m happy to play around with more debugging.
-
By all means, do what you will with it, and most of all, have fun!
-
Also have to remember that the pi is limited in just about every way…
-
Especially remember that electron and gifs are really a bad combination especially on the raspeberry pi since it does not use hardware acelleration
-
I had thought about using an intervalTimer which showed a list of images in succession, but I think that would be worse than a GIF for the Raspi.
-
@chef i have been using MMM-ImagesPhotos or MMM-ImageSlideshow and don’t see the out of memory issue… don’t have any gifs in the image list tho
-
When you directly display MM2 on your raspberrypi you could do an overlay with omxplayer. it supports hardware acceleration which makes it run really smooth with gifs
