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…

@sdetweil I don’t believe it’s the modules.

Leap 16 fresh install is fine with a fresh MM install as well. I upgraded the server again from Leap 15 to Leap16. Before the upgrade, I removed node and npm modules linked to version 18 and MM was running fine in all mannners.

After the upgrade, I made a couple of system-level changes (like disabling the firewall that it forces on you) and added the node/npm modules for version 24 and wasn’t able to start the mirror with pm2 like normal… it continues to throw errors about node18 being missing. However, running the mm.sh script manually or launching the mirror via either npm start server or node --run server works fine.

Did more digging around and found that the issue lies solely in the hands of pm2… the back-end environment was created back in the node/npm 18 days and that was saved in the configuration. The only way to find it was to do a “pm2 dump” and scan the file.

Once I knew it was pm2 for sure, the actual fix was pretty simple:

pm2 save
npm install pm2 -g
pm2 update
pm2 unstartup
pm2 startup

If MM wasn’t still configured as a process…

cd ~
pm2 start mm.sh
pm2 save

I’m running on Leap 16, latest patches, node/npm 18 is uninstalled, mirror is properly auto-launching. Now, I can update the modules and the mirror… But not before I do a snapshot! lol

@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… :)

@sdetweil Yeah… I should have said I updated to the latest version of Bullseye with all patches. I haven’t made the last step to Bookworm yet…

@thgmirror Not really an option for me.

How does the site admin not understand that this is counter-productive to the site?

@sdetweil

I don’t see anything in the script to do the pm2 save or a “pm2 start mm --udpate-env” so that it would use the new version of node. Not sure if your script is already gracefully handling those kinds of updates for the MM startup.

Also, since the script seems to assume Debian-based distro’s, dpkg doesn’t execute on my system and I’m not entirely sure if the script would effectively update my system for me. Thoughts on that?

@sdetweil

Do any of your scripts check for pm2 and update the version during any installs or upgrades? Seems like, for the latter at least, that would be helpful.

My original mirror was obviously built quite a long time ago as the node18 variable was linked to the startup process. No idea how many MM revisions I went through between then and now and was always running on the much older version of node no matter what I did to upgrade the main system.

@sdetweil I don’t believe it’s the modules.

Leap 16 fresh install is fine with a fresh MM install as well. I upgraded the server again from Leap 15 to Leap16. Before the upgrade, I removed node and npm modules linked to version 18 and MM was running fine in all mannners.

After the upgrade, I made a couple of system-level changes (like disabling the firewall that it forces on you) and added the node/npm modules for version 24 and wasn’t able to start the mirror with pm2 like normal… it continues to throw errors about node18 being missing. However, running the mm.sh script manually or launching the mirror via either npm start server or node --run server works fine.

Did more digging around and found that the issue lies solely in the hands of pm2… the back-end environment was created back in the node/npm 18 days and that was saved in the configuration. The only way to find it was to do a “pm2 dump” and scan the file.

Once I knew it was pm2 for sure, the actual fix was pretty simple:

pm2 save
npm install pm2 -g
pm2 update
pm2 unstartup
pm2 startup

If MM wasn’t still configured as a process…

cd ~
pm2 start mm.sh
pm2 save

I’m running on Leap 16, latest patches, node/npm 18 is uninstalled, mirror is properly auto-launching. Now, I can update the modules and the mirror… But not before I do a snapshot! lol

@sdetweil The bug may have been around for a while… my mm.sh script is launching the mirror via “npm run server” and that script is what pm2 uses to launch the mirror. I’ve been doing it that way for a long time, likely because the serverOnly config setting wasn’t working.

If I actively run “npm run server” and then do “ps aux |grep node” I do not see anything related to node18 in the process list.

@sdetweil As mentioned, I reverted… back to whatever I was previously running.

Working on a fresh Leap 16 install, fresh MM install. Running into problems with inability to connect to display (running serveronly, no display connected). Seems that the serverOnly config setting may not get used any more? I have to start the server with “node --run server” to get past the display errors.

BTW… fresh install, there is no ‘default’ directory under modules… Thoughts?

@sdetweil I reverted back again (Leap 15.6)

I recall seeing a 36 or something somewhere if that helps.

I had even moved the MM folder off and tried starting again, re-installed npm 22 and 24, and the errors were exactly the same. Something is out-of-whack somewhere and I haven’t had the time to dig deep enough to understand if it’s MM, my linux machine, or a combo.

I’m considering trying a fresh Leap 16 build and seeing what happens. If that works without an issue, then at least I know “it’s possible.”

@sdetweil Yep.

The only thing is puts on the screen of any potential interest is

[ -f node_modules/.bin/husky ] && husky || echo no husky installed

@sdetweil I did an OS upgrade to move to Leap 16. I had a couple of quirky issues with that and corrected them. Post-upgrade, I added node24 packages but Leap 16 no longer supports the node18 packages (so, those are gone).

I updated the modules and then MM and now it throws an error claiming that it can’t locate node18 executable. I tried searching for some sort of symbolic link, but I’m not finding anything.

@sdetweil I’ll have to try again a little later today maybe… I had to revert the snapshot (removing the module updates) to get it running again.

Update…

Updating the modules crashes the server. So, I’m going to have to get the main server updated… I had to revert to a prior snapshot to get the MM server running again.