I used an iterative command for this because there are so many photos:

cd ~MagicMirror
find < path to images >/* -exec node_modules/.bin/electron file:///{} \;

For each file in that directory, it would launch the electron browser and open the image. Because electron continues to run until it is terminated, this puts one image at a time on the screen. After each one loaded, I would simply click “X” to close the browser and it would move on to the next image.

While I -did- see one specific image file appear to load but not actually show any content (initially), I believe this may have been an issue with the fact that I walked away from the process for about ten minutes. Expanding the browser window caused it to re-render and it displayed fine. Additionally, this is an image that I have personally seen on the screen many times with no apparent link to any crashes.

It seems that any image-specific issues are possibly cumulative since loading each one in turn starts with a fresh memory allocation as the browser exits after each image.

What would I be looking for?

Turns out I’m wrong on two counts…

1. I -have- been testing the caching disable extensively as it’s currently disabled. :)

2. There is not a slow-paint issue for images with caching disabled.

Unfortunately, I can now say that I’m pretty comfortable with the assessment of this NOT being a caching issue. With caching disabled for electron, the issue has now occurred multiple times in just the last 4-5 hours.

I’m not sure that this is a caching error as it seems related very directly to the displaying of images but “rears up” differently based on the module. In the prior module I was using, displaying ANY graphical content lead to a quick demise of the system (within 15 minutes or so, typically). With the current module, everything was 100% fine until I cropped some of the images. The current module is one you are using with zero images, so there has to be something about the crop method I used that threw things out of whack.

Even if it IS a straight-up caching issue, I can’t disable caching because the image display process looks poor. I’ve tried with caching disabled and it is not at all smooth, and I also haven’t tested that anywhere near enough to actually validate that it corrects anything.

Is there a way for me to be able to at least understand the process in effect when this error gets thrown? The entry in the error log seems super generic with no real information along with it.

Up until yesterday, my MM had been running reliably over a period of days without blanking the screen or locking up.

I have a few default modules (calendar, currentweather, and weatherforecast) enabled and only one third-party (MMM-ImagesPhotos). After correcting some CSS and config.js mistakes over the last couple of days so that it displays what I want, and how I want it, I decided to move on to tinkering with the images themselves.

I have a lot of photos that I am using in the background. Many were shot on my DSLR (24MP) and some came from other DSLR’s (Disney’s Photo Pass) and some smart phones. Using the default image size (3:2 ration) for landscape left gray letterbox bars on the sides of the screen. I began cropping the photos from 3:2 to 16:9 and replacing the original files.

While the photos display mostly “perfect” (for some reason, I am still seeing what looks like a 1-2 pixel “frame” around many images that should be full screen), the RPi (Model 3 v1.2) is back to blanking the screen after some period of run time and the logs show “Out of memory.” I don’t know if it’s related, but I was using a different module to display photos in the background (MMM-BackgroundSlideshow) and was using the exact same set of photos. With that module, I had not cropped ANY of the photos but was getting the same sort of “Out of memory” behavior.

I’ve seen some other possibly anecdotal ‘reports’ of certain image-related details causing this sort of error, so I’m wondering if it’s at all related. I also read through a thread from not-that-long-ago where various bugs in the notification module were being fixed (and the fixes being tested), but there wasn’t any follow-up in that thread as to the status.

I’ve also tried increasing swap space on the MM, but that has not made any difference.

Any tips on how to go about starting to troubleshoot this? The device itself remains 100% responsive and network access is fine. I can send signals to turn the display on and off and that works as well. The only way to “fix” the solid black screen is to restart MM or the entire device.

@sdetweil said in Calendar Doesn't Honor custom.css for Background:

@ember1205 said in Calendar Doesn't Honor custom.css for Background:

the Developer options with a real browser

electron is a real browser, so you can do this ON the mirror,
or from your desktop if the config parms allow remote system access.

I always forget that I can use local browser to view developer window

Now that you mention it, I have used the developer options directly on the appliance and should have remembered that. Thanks for the reminder!

@sdetweil

I found and fixed it (sort of). I had added content to my custom.css file to create a blurred background image as I was experimenting with some display options. I commented that content out (or so I thought) and placed all of these controls “after” that section in the custom.css file.

Through a variety of changes that I was making to try and track this down, I noticed through viewing the Developer options with a real browser and looking at the elements that whatever section came first after my blurred background section wasn’t being picked up. As I rolled the changes down to the bottom, I was seeing different sections stop working.

Seems to be all fixed now, and is clearly not a bug in the product but was a bug in my custom.css content. After deleting the content, all is displaying properly.

@sdetweil

Calendar still does not pick up any CSS controls from the main custom.css file. Here is a snippet of what I added:

.calendar {
  background-color:rgba(32,32,32,0.6);
  border-radius:8px;
  padding:8px;
}

I modified the other sections to look like this:

.module.clock {
  background-color:rgba(32,32,32,0.6);
  border-radius:8px;
  padding:8px;
}

.module.currentweather {
  background-color:rgba(32,32,32,0.6);
  border-radius:8px;
  padding:8px;
}

.module.weatherforecast {
  background-color:rgba(32,32,32,0.6);
  border-radius:8px;
  padding:8px;
}

They work fine “either way”. Calendar refuses to pick up the formatting from the custom.css file it seems and I have to put the controls into the calendar.css file in the module’s directory.

@sdetweil

Ok. I will look into making those changes and see if I can get it working the way that I want.

Why does “module.currentweather” work fine, though (along with the others that I mentioned)? CSS has always been a weak spot for me…

@sdetweil What does “not the world module” mean? Just seeing that now, and not following…

@sdetweil

Sigh. Thanks. :)

@sdetweil

That’s how it is in my config.js (no quotes). The quotes were used here to isolate it in the post only.

                {
                        module: "clock",
                        position: "top_left",
                        displaySeconds: false,
                },

It has no effect.

@sdetweil

In custom.css, this does not work:

.module.calendar {
  background-color:rgba(32,32,32,0.6);
  border-radius:8px;
  padding:8px;
}

Also, in custom.css, this DOES work:

.module.currentweather {
  background-color:rgba(32,32,32,0.6);
  border-radius:8px;
  padding:8px;
}

.module.weatherforecast {
  background-color:rgba(32,32,32,0.6);
  border-radius:8px;
  padding:8px;
}

.module.clock {
  background-color:rgba(32,32,32,0.6);
  border-radius:8px;
  padding:8px;
}

Although I can not find any statements that would say or imply that the digital clock doesn’t support “displaySeconds: false”, setting that value seems to have no effect.

I attempted to add the following to my custom.css:

.module.calendar {
  background-color:rgba(32,32,32,0.6);
  border-radius:8px;
  padding:8px;
}

It did not work as expected, nor as it did for clock, currentweather, or weatherforecast. I had to insert that code into the ~/MagicMirror/modules/default/calendar/calendar.css module as:

.calendar {
  background-color:rgba(32,32,32,0.6);
  border-radius:8px;
  padding:8px;
}

This is the only way it would provide the opaque background that I wanted.

Thoughts?

@sdetweil

I believe the rules are less important than the consequences. I don’t believe WLAN has a good track record overall of waking up from a sleep state. And, regardless of how much it’s directly used, you can bet that the one time it won’t work is when you try using the remote control module to power it down. :)

@sdetweil

-Should- the WLAN power setting be changed? It would seem that this would be a wise approach to ensure it doesn’t go into powersave mode.

Some additional notes:

• The screensaver settings appear to have been set in the /etc/xdg/lxsession/LXDE-pi/autostart file
• No settings have been adjusted in /etc/lightdm/lightdm.conf
• The mouse pointer auto remove configuration has not been completed, but there appears to be no issue with the pointer remaining on the screen once Electron loads
• There was no change made to the system to disable power saving on the WLAN interface - as a result, the interface seemingly “could” go into powersave mode and affect network connectivity (I have not yet experienced an issue with this)

install starting  - Fri Dec 20 08:32:44 EST 2019
installing on armv7l processor system
the os is Distributor ID: Raspbian Description: Raspbian GNU/Linux 10 (buster) Release: 10 Codename: buster
Updating packages ...
Hit:1 http://archive.raspberrypi.org/debian buster InRelease Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB] Get:3 http://raspbian.raspberrypi.org/raspbian buste
r/main armhf Packages [13.0 MB] Fetched 13.0 MB in 15s (852 kB/s) Reading package lists...
apt-get update  completed ok
apt upgrade result =rc=0 Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following package was automatically installed and is no longer required:
  point-rpi
Use 'sudo apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Installing helper tools ...
Check current Node installation ...
Node currently installed. Checking version number.
Minimum Node version: v10.1.0
Installed Node version: v10.15.2
No Node.js upgrade necessary.
Check current NPM installation ...
NPM currently installed. Checking version number.
Minimum npm version: V6.0.0
Installed npm version: V5.8.0
npm should be upgraded.
Installing npm ...
Reading package lists...
Building dependency tree...
Reading state information...
npm is already the newest version (5.8.0+ds6-4).
npm set to manually installed.
The following package was automatically installed and is no longer required:
  point-rpi
Use 'sudo apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
upgrading npm to latest
/usr/local/bin/npm -> /usr/local/lib/node_modules/npm/bin/npm-cli.js
/usr/local/bin/npx -> /usr/local/lib/node_modules/npm/bin/npx-cli.js
+ npm@6.13.4
added 430 packages from 854 contributors in 42.042s
npm installation Done! version=V6.13.4
Cloning MagicMirror ...
Cloning MagicMirror Done!
Installing dependencies ...
Dependencies installation Done!
setting up initial config.js
Check plymouth installation ...
Splashscreen: Checking themes directory.
Splashscreen: Create theme directory if not exists.
Splashscreen: Changed theme to MagicMirror successfully.
install and setup pm2
pm2 not installed, installing
pm2 install result /usr/local/bin/pm2 -> /usr/local/lib/node_modules/pm2/bin/pm2 /usr/local/bin/pm2-dev -> /usr/local/lib/node_modules/pm2/bin/pm2-dev /usr/local/bin/pm2-docker -> /usr/lo
cal/lib/node_modules/pm2/bin/pm2-docker /usr/local/bin/pm2-runtime -> /usr/local/lib/node_modules/pm2/bin/pm2-runtime npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.1.2 (node_
modules/pm2/node_modules/fsevents): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arc
h":"arm"}) + pm2@4.2.1 added 207 packages from 202 contributors in 38.506s
get the pm2 platform specific startup command
startup command = sudo env PATH=$PATH:/usr/bin:/bin /usr/local/lib/node_modules/pm2/bin/pm2 startup systemd -u pi --hp /home/pi

                        -------------

__/\\\\\\\\\\\\\____/\\\\____________/\\\\____/\\\\\\\\\_____
 _\/\\\/////////\\\_\/\\\\\\________/\\\\\\__/\\\///////\\\___
  _\/\\\_______\/\\\_\/\\\//\\\____/\\\//\\\_\///______\//\\\__
   _\/\\\\\\\\\\\\\/__\/\\\\///\\\/\\\/_\/\\\___________/\\\/___
    _\/\\\/////////____\/\\\__\///\\\/___\/\\\________/\\\//_____
     _\/\\\_____________\/\\\____\///_____\/\\\_____/\\\//________
      _\/\\\_____________\/\\\_____________\/\\\___/\\\/___________
       _\/\\\_____________\/\\\_____________\/\\\__/\\\\\\\\\\\\\\\_
        _\///______________\///______________\///__\///////////////__


                          Runtime Edition

        PM2 is a Production Process Manager for Node.js applications
                     with a built-in Load Balancer.

                Start and Daemonize any application:
                $ pm2 start app.js

                Load Balance 4 instances of api.js:
                $ pm2 start api.js -i 4

                Monitor in production:
                $ pm2 monitor

                Make pm2 auto-boot at server restart:
                $ pm2 startup

                To go further checkout:
                http://pm2.io/


                        -------------

[PM2] Init System found: systemd
Platform systemd
Template
[Unit]
Description=PM2 process manager
Documentation=https://pm2.keymetrics.io/
After=network.target

[Service]
Type=forking
User=pi
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
Environment=PATH=$PATH:/usr/bin:/bin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
Environment=PM2_HOME=/home/pi/.pm2
PIDFile=/home/pi/.pm2/pm2.pid
Restart=on-failure

ExecStart=/usr/local/lib/node_modules/pm2/bin/pm2 resurrect
ExecReload=/usr/local/lib/node_modules/pm2/bin/pm2 reload all
ExecStop=/usr/local/lib/node_modules/pm2/bin/pm2 kill

[Install]
WantedBy=multi-user.target

Target path
/etc/systemd/system/pm2-pi.service
Command list
[ 'systemctl enable pm2-pi' ]
[PM2] Writing init configuration in /etc/systemd/system/pm2-pi.service
[PM2] Making script booting at startup...
[PM2] [-] Executing: systemctl enable pm2-pi...
[PM2] [v] Command successfully executed.
+---------------------------------------+
[PM2] Freeze a process list on reboot via:
$ pm2 save

[PM2] Remove init script via:
$ pm2 unstartup systemd
pm2 startup command done
configure the pm2 config file for MagicMirror
start MagicMirror via pm2 now
save MagicMirror pm2 config now
disable screensaver via lxsession
We're ready! Run pm2 start MagicMirror from the ~/MagicMirror directory to start your MagicMirror.
install completed - Fri Dec 20 08:59:08 EST 2019

@sdetweil Agreed. And, if it were me, I would do it that way.

Cron job to check for updates and determine if the file gets updated
If the file was updated, either send notification to load new image in the module, or just restart MM
Use something along the lines of MMM-EasyBack as a module to load the background image