Hmmm. Not sure about other browsers since I had shut those down. I’ll wait until it crashes again and see if a secondary browser will keep running.

Well, it isn’t a LOT of progress, but it’s progress.

It’s still crashing. But I managed to get a core dump. And it says that it’s Electron that’s crashing. The initial output from bt has me a little confused as I can’t tell if it didn’t load the symbol file correctly, or if the info just “unknown”. Here’s what I get from a bt command:

Core was generated by `/home/pi/MagicMirror/node_modules/electron/dist/electron --type=renderer --auto'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0  0x02760514 in ?? ()
[Current thread is 1 (LWP 6298)]
(gdb) bt
#0  0x02760514 in ?? ()
#1  0x027603d8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Not really sure if there’s anywhere to go from here. :/

So, the extra “stress” isn’t actually stress on the Pi at all?

Updated and restarted the MM process. I will keep the three browsers hitting it and wait and see if it errors out again. Sometimes, this can literally take days while other times it can occur multiple times in an hour.

should it be:

img=null;

???

In my situation, the UI goes all black and the cursor appears (no mouse or keyboard connected). There’s a generic “out of memory” error entered into the log file. Restarting MM is the only way I’ve found to get it back up and running.

The photo module I’m running is your fork with the more recent changes to allow the blurring of the same image behind the full-view image. Any thoughts on anything that could/should be added to try and capture more in the logs? Is there an increased logging level I could be using in MM itself? Stack traces when it fails? Before it fails? Anything come to mind that might give me a new avenue?

The issue doesn’t seem to appear if I am not using the photo module. But, that could be because the other, more basic modules don’t use resources as intensively. We’ve compared notes on RPi, kernel, build, etc. and not found anything that seems to be materially different with the one exception being the specific image files in use.

By adding an external browser, it crashed in only a few minutes. I’m going to let it keep running with the additional external browser to see if it causes it crash much more quickly on a more continuous basis.

If I can cause it to crash quickly on a repeated basis, it gives me an opportunity to try testing specific image files. It’s possible that this is a cumulative problem that is related to a small memory loss that gets added to on the load of additional errant files.

UPDATE: So much for that theory… I am currently running Electron plus an external instance of Chrome on Windows and Safari on MacOS. No “quick crashes.”

Your suggestion incorporates multiple changes, though… Stopping Electron and Starting Chromium while also changing the operating mode. No?

I’ve changed the config.js to both

serverOnly: true,

and

serverOnly:"true",

and neither one prevents Electron from starting.

I’ve now also tried

serverOnly:true,

Understood that there isn’t new software installed, but this would mean no additional software actively running on the Pi (Electron would be stopped, and all browser software would be running from a different machine).

Would that be any different than running it in server mode and accessing it from a browser on my computer across the network? That would be simpler to set up and wouldn’t add more running software onto the Pi…

Thought I would update this…

Still broken.

I have the latest MM as a fresh install on a brand new RPi with a new power adapter, using a brand new SDCard, connected to a different monitor, using a different HDMI cable, and it’s all plugged in to an outlet at an entirely different house in a different area of the state (different sections of the grid). I have the same few, basic modules installed and have added the photos module discussed here. It crashes and hangs randomly with “out of memory” errors just like the other one.

The only thing the same between the two is the photo collection. I’ve not found any consistency in the past on it failing with any specific photos so troubleshooting this seems like it’s going to be impossible.

Most monitors are IPS panels while most TV’s are VA panels. IPS has wider viewing angles with consistent color. The VA panels have better refresh rates for motion (which is not commonly needed for something like a mirror).

TV’s can be an easy choice because they can be much more available and a remote could be useful. A monitor will generally make for a preferred screen by having better viewing angles and being lighter overall.

I have a script that I run every 15 minutes via cron that checks for updates to the config file. It compares the time and date stamp of the config file against the time and date stamp of the pid file from when MM was started. If the config file is newer, it restarts MM.

        if [ /home/pi/MagicMirror/config/config.js -nt /home/pi/.pm2/pids/mm-0.pid ]; then
                /usr/bin/pm2 restart mm
        fi

One of the challenges doing this would likely have is the fact that MM is designed to be without a keyboard and mouse, and recipes on web pages are never at the top of the page. “Sending a link” would ultimately result in that link being opened on the MM and it would display from the top of the page. How would you scroll to get to what you need? Yes, I could see where some level of integration of voice commands could help, but I think it would be problematic.

Something you could consider doing would be looking at one of the Google modules that could open a “photo” (nothing but an image file of any type) from your Google Photos or Google Drive and then taking a screen shot of the recipe and saving it to that location. The module would need to “find it” in order to display it and then you would delete it later on for the displaying of it to go away.

If you’re not using the MM as a photo frame, you could do this similarly with one of the photo frame setups, too.

@sdetweil Agreed. And, it would still require a method for the module to “register” with the remote thermometer of its existence when it loads so that initial temp and updates will be transmitted.

Why not write the module that goes into MM and then use a script on the thermometer to update the module when the temp changes? If your thermometer is measuring the internal temp of a home, and that changes infrequently because the heat or AC is on, there’s no point in polling the thermometer every five minutes to see what the temp is. :)

@dwburger I think you’re on a good path with this…Keep us posted…

@dwburger You’re trying to put a band-aid on a gushing wound - WiFi issues, display problems, PM2 not starting MM…

Tackle one problem at a time to get them all fixed instead of relying on a restart to fix one issue and letting it cause two others.

@bhepler

I think you’re missing the point.

If you have two modules, X and Y, and you disable one and the problem persists? What’s your diagnosis?

How long do you allow the system to run with one module disabled and no fault before you are able to actually, definitively, able to declare that the problem is the sole result of that module?

Even if you can declare the issue gone, how do you know that it wasn’t an issue related to the combination of modules?

Without explicit logging and debug information to actually see a stack trace of the fault, there is no way to declare “anything” by disabling a module.