Cool. I download the latest one and try it out.

Glad I can help you keep improving your code! lol

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.

@raf Are you volunteering? :)

Seriously - You won’t be anywhere near as well-versed as if you can figure it out on your own. And documenting your learnings to help others is how all of this stuff grows and improves. I’ve pestered @sdetweil plenty about a lot - much of his input has been to help me understand where to look, but he has also done some coding and such on his side. I’ve offered back some things I learned along the way that he has then incorporated and I’m now going to look into helping to extend and enhance some work he has done by doing the coding myself. It take a village, as they say…

@raf So, figure out what’s incorrect and help get it updated. The doc you’re trying to work from was built in that same way at one point…

Update… 30 full days since my last post about stability and have not experienced a single crash on either mirror. So, Electron is definitely the source of the problem.

Thank you to @sdetweil for the assistance in swapping over to Chromium and getting things to a stable state.

UPDATE: At this point, I’m closing in on a full week of operating two mirrors without issue. I’ve changed to running Chromium instead of Electron and it’s working well all around. Here are some details of the operation in case it’s useful:

• Pi 3 Model B (one UK, one China)
• MM 2.12.0
• Native modules configured: WeatherForecast, CurrentWeather (both weather modules set to different locations as the two Pi’s are in different locations), clock, calendar (2 instances, 2 different Google calendars), alert, updatenotification
• Third-party modules: MMM-ImagesPhotos (@sdetweil version)
• Customizations:
• • Modified the WeatherForecast module according to this thread to get 5 days of forecast data back after recent MM update: https://forum.magicmirror.builders/topic/13187/weatherforecast-showing-only-two-days/31?_=1601303807634
• • Converted to using Chromium instead of Electron locally as detailed in this thread
• • Chromium update / notice disabled via the step from a couple of posts prior to this one
• • Allow connections from local LAN addresses
• Pi connected to a smart plug that turns on each day at 7AM, cron job to execute “init 0” each day at 11PM, smart plug turns off at 11:05PM

Prior to successfully switching over to Chromium, the devices would crash at least once every other day (at least one of them would crash during a 48 hour window), although it was much more common to see each one crash multiple times per day. There was no consistency to which one would crash, why, when, etc. The “crash” in question was a black screen on the mirror and no visible info being output although the mouse cursor would sometimes appear. I wrote a cron job that would run every five minutes, look up the location of the pm2 error logs, check to see if there was an “out of memory” error in the log, and do a restart of MM if there was (the restart consisted of shut down, log flush, and start). This job ran every five minutes and would silently exit if there was no error as the mirror was running ok.

Since the switchover, I have seen zero crashes on either device in almost seven days of operation.

Electron has been discussed ad nauseum as having a variety of shortcomings, bugs, issues, etc. - especially in the old version being used with MM. At this point, I have to wonder why it’s still not only the default but the ‘only’ browser that’s really discussed for use with MM. It would seem that it’s time to either forklift an upgrade to it within MM or switch to something else (at a minimum, at least provide a well-documented alternative).

I’m grateful to @sdetweil for his assistance with this, especially since it really took a calendar year almost to get to a point where it’s seemingly working as expected now.

@sdetweil

Now I have to find something else to break… sigh… :)

Makes sense… Are there plans, then, to change the startup to a single command (script) that will read some sort of config file or accept a command-line parameter to control what gets started? I had to do a bit of digging to find the different (correct) commands to use to start the server on a headless machine and the client on a Pi and then put them into the “mm.sh” startup script so that PM2 could load each of them correctly. This doesn’t seem to match up with what’s documented, either.

In the main configuration file, there is a section to specify “serveronly” as an option which is supposed to NOT load any client resources. Attempting to start the mirror with npm start doesn’t seem to actually “respect” this option and it constantly complains about client-side components that may not be installed or operational.

I’ve also not found anywhere in the configuration where you might be able to specify “clientonly” and indicate the server to connect to. Why is this? Why do I need three different ways of starting the mirror depending on if I’m running a server, a client, or both?

What am I missing here?

After a LOT of different attempts at upgrades, fail-backs, new installs, etc., I believe I finally corrected the issue…

It appears that PM2 was either somehow corrupted during an update attempt or just simply too far out of date. Attempting to run PM2 with certain command options (like stop or even status) was resulting in errors indicating some sort of circular reference. After doing a forced upgrade to the latest version, it stopped showing these errors and the mirror is to running as expected.

I did make some additional changes that include copying the core MM directory off to another linux host where I now run the mirror as a server. The RPi is now purely a client and it loads noticeably quicker as a result.

Pretty sure it’s an out of memory issue. Once it crashes, the free memory jumps way up then trends back down once it restarts.

I’ve also discovered that this seems to be purely a “client” problem as I can connect to the Pi from a remote machine using a web browser and it will run just fine without any hiccups while the local client on the Pi crashes about every 60-70 seconds which correlates to two load intervals for photos. Maybe the MMM-ImagesPhotos module isn’t releasing memory properly?

The device is restarting for what appears to be out of memory / swap space issues. Every time the system crashes and restarts, /dev/shm is at zero available space.

This location appears to be where the processes are storing content from the image files that are being loaded and it’s apparently causing something to overrun the available space. I have added images, but that was a couple of weeks ago (before even applying the OS updates) and everything ran perfectly fine.

Forgive me, but “can’t do” what, exactly?

I have reverted to the exact software, install, and configuration that was in place before running the upgrade by renaming the upgraded directory and then renaming the backed up directory back to the original name. Unless there are files downloaded and stored -outside- of the MagicMirror directory, this should have ensured a complete reversion to the working files.

Umm… git stash pop?

I renamed the upgraded install to “MM-Upgraded” and then renamed my copied directory back to “MagicMirror”. Neither of them works properly at this point and the copied directory was never touched during the upgrade process.

Email sent…

pi 3B+

uname -a output

Linux raspberrypi 5.10.103-v7+ #1529 SMP Tue Mar 8 12:21:37 GMT 2022 armv7l GNU/Linux

How do I post the log? Far too large to go into a post, and isn’t a support file type to attach.

Error on my part… I still have the upgraded directory.

There is no info from the logs that I can tell that shows any sort of crash or anything. And the line from the npm logs just shows the run-start.sh command.