Third-Party Module - how to get help?

ember1205

This line just keeps repeating:

MMM-BackgroundSlideshow received a system notification: CLOCK_SECOND

The only red text is for an error with the weather module then it states that it’s changing to a different forecast.

ember1205

I thought I would follow this up as I have found and solved this specific issue.

Long story short, this particular module has a pre-defined list of file extensions that it will recognize as images. For some reason, I pulled a copy of image files from two different locations and the extension changed from JPG to JPEG. The former is default, the latter is not. I updated the module configuration and it started working again.

I also discovered that the module is running out of memory while running. The error seems to be very consistent although the image in place when it crashes is not. I’ve posted an issue to the module owner’s repository to see what help that might bring.

sdetweil

@ember1205 you could try to force electron not to cache images

edit the js/electron.js file and add this line

	app.commandLine.appendSwitch('disable-http-cache');

function createWindow() {
	app.commandLine.appendSwitch("autoplay-policy", "no-user-gesture-required");
----> here

ember1205

@sdetweil said in Third-Party Module - how to get help?:

app.commandLine.appendSwitch(‘disable-http-cache’);

Thanks. I have made the change and restarted the mirror.

I’m running with only this module and the clock enabled and am finding that having the image caching disabled (so far) is significantly slowing down the rendering of the images on screen.

Is there a way to set the node.js maximum memory or set a limit on cache size? I have found some commentary that seems to say that node.js will use up to 1.7G of RAM by default and have no idea if there is anything in any of these configuration files that would lower that limit using the settings:

--max-old-space-size={limit in KB} --optimize-for-size --max-executable-size={limit in KB}

Given that my system is 1GB of RAM, and the default for node.js is to use up to 1.7GB, I could see where it could conceivably be trying to use memory beyond the bounds of the system, especially if there were some sort of issue with the underlying OS and its interaction with node.js to control the memory usage.

sdetweil

@ember1205 you should increase the swap space .

https://wpitchoune.net/tricks/raspberry_pi3_increase_swap_size.html

yes, lack of cache will slow down rendering.
I added javascript code to the other module to wait til the image was loaded before showing,
made a huge improvement, no lag rendering

you could try it
https://github.com/sdetweil/MMM-ImagesPhotos
git clone that and then use this in config

		{
			module: "MMM-ImagesPhotos",
			position: "fullscreen",
			config: {
				opacity: 0.9, 
				animationSpeed: 0,
				updateInterval: 30000,  // how often to change pic
				backgroundColor: "#808080", // color around pic (if u want something other than black)
			},
		},

u have to put images in the uploads folder,
or make a link (ln command) for the uploads folder where the pics are (I use my linux server, external usb drive)

cd ~/MagicMirror/modules/MMM-ImagesPhotos
ls -laF
lrwxrwxrwx   1 sam sam    45 Dec 12 08:53 uploads -> /media/buildserver/media/Photos/selectedpics//

add

disabled: true,

the the existing module definition (after the name)
to turn it off, without changing anything

sdetweil

the command

free -m

will show u memory usage

nano 
sam@nano:~/MagicMirror$ free -m
              total        used        free      shared  buff/cache   available
Mem:           3956        2097         359         559        1499        1149
Swap:          1978         460        1517

pi4 -4gig, default swap space
free -m
              total        used        free      shared  buff/cache   available
Mem:           3906         650        2053         447        1201        2656
Swap:            99           3          96

ember1205

@sdetweil said in Third-Party Module - how to get help?:

https://wpitchoune.net/tricks/raspberry_pi3_increase_swap_size.html

I will give this a shot. Given that each time the slideshow has died, it has indicated that it ran out of memory at roughly 100Mb (and the default swap is 100Mb), this could definitely be related. I’ll try doubling it to see what happens with this module.

I was going to try tackling the transitioning to prevent changing to the new image until it was rendered (to prevent the “painting”), but need the memory issue fixed first. :)

Does your image module contain the JS code you were referring to that hides the image until it’s rendered?

sdetweil

@ember1205 yes, it contains the code for the transition handling.

I would make the swap 1 gig… its only a little disk (memory card) space…

the code.

basically it adds an img (appends) to the div to display, the image is hidden,
then there is an onload handler, that gets notified when the image is loaded (not yet visible)
it also adjusts the image size to keep the proportions correct, (css background-size:cover and contain both distort the image)

it makes the image visible, and starts the timer for the next image.

it then checks to see if there are TWO images in the div,
if so, it hides the 1st, shows the second and removes the 1st (old image)
repeat

ember1205

@sdetweil

I will give your code a try. Increasing the swap size and re-enabling the cache resulted in another almost immediate crash.

:(

sdetweil

@ember1205 hm… mine runs like a top on pi0 , pi3 b+, pi4, odroid, jetson nano , macOs, ubuntu

my selected pics holds 100 pics, some as large as 15meg. 7.4 meg avg