@sdetweil thanks, but i don’t think i’ll be providing my credit card details to a service for them just to keep it on file for the unlikely possibility that i’d make 1000+ API calls a day.
I’ll just comment out or remove that section of my config.js file.

Since updating MM to 2.35 from 2.34, the default weather module is no longer displaying the forecast.
I use :
“openweathermap” option for the weatherProvider: key;
“forecast” option for the type: key; and
“/forecast” option for the weatherEndpoint: key

Other than updating the apiVersion from 2.5 to 3.0 in the config, no other changes have been made to any other keys within the module’s config and the module only shows “WEATHER FORECAST” as per the header: key, and then only displays Loading … where the forecast should be displayed.

My config for the module is as follows:

{
    module: "weather",
    position: "top_right",
    header: "WEATHER FORECAST",
    config: {
        // General Options
        weatherProvider: "openweathermap",
        type: "forecast",
        roundTemp: true,
        degreeLabel: true,
        updateInterval: 300000,
        showPeriod: true,
        showPeriodUpper: false,
        appendLocationNameToHeader: false,
        // Forecast Options
        tableClass: "xsmall",
        colored: true,
        fade: false,
        maxNumberOfDays: 5,
        // OpenWeatherMap Options
        apiVersion: "3.0",
        apiBase: "https://api.openweathermap.org/data/",
        weatherEndpoint: "/forecast",
        location: "Melbourne,Australia",
        apiKey: "xxxxx",
    
},

What am i missing in this latest release in the config of this module in MM 2.35?

@sdetweil
OK, so after a few days, my MM is still on Debian12 and i’m now seeing the same constant/frequent reload of the default calendar.

What logs should I be looking in and what should I be looking for in them?

@sdetweil said in Default Calendar module frequently refreshes:

@DarrenO-0 sorry, not quite sure what you’ve said here

You specified tableClass twice in the config of a single calendar module declaration?

JavaScript should take the second, and ignore the first
JSON.parse() should overlay the first w the second

And tableClass is only used in the presentation of the events long after the broadcast message is sent

Correct, yes.
I would have assumed, and expect, that the second specified instance of “tableClass” would supersede the first, but for some reason when I removed either instance and re-saved the config, the calendar has been rock-solid and no longer performs the constant/frequent refresh outside of the fetchInterval value.

Was the duplicate value the cause and removing it was the solution?
Was simply re-saving the config, to force MM to re-read it, the solution?
I don’t know, but it is all now working as expected - i see the calendar temporarily fade out and redisplay according to the configured 5min interval
When viewing the live tail of pm2 logs --lines=15, i’m no longer seeing a constant display of the “Broadcasting…” of each calendar throughout the configured fetchInterval. I now only and correctly see it update according to the fetchInterval value.

@sdetweil
one thing i’ve now noticed since removing the duplicate tableClass entry in the calendar module’s config, when i now run :
pm2 logs --lines=15
i am now seeing the Broadcasting ### events entries calendars update on the scheduled intervals.

Prior, while i was having the issue, i would see a constant updating of the live view of pm2 logs.

@sdetweil said in Default Calendar module frequently refreshes:

@DarrenO-0 I rejected your post w the log entries, see the notification message I sent

The calendar entries for the logs were unique.
I removed the true component of the email address prior to the “@” and replaced them with calendaruser1… calendaruser4

Incidentally, i’ve been back through the config.js file for the default calendar and found that I had specified tableClass= twice.
The fIrst instance had a value of “small” with the bulk of the other options.
The second instance had a value of “xsmall” and was between the customEvents[] and calendars[] arrays.

I removed the second instance and changed the value of the first to “xsmall”.
Saving the config automatically restarted MM and it appears to have resolved the matter as it hasn’t repeated the issue in the last hour, but i’ll continue to monitor over the next couple of days.
Not sure how that one line could have caused the issue… Any ideas???

@sdetweil said in Default Calendar module frequently refreshes:

@DarrenO-0 thx. Id really like to see the logs from both for the event broadcast cycle

There was a big calendar parser change in. 33 and another coming in. 34

I’d upgraded to .33 in mid-Oct and had only upgraded Debian from 12 to 13 earlier this month but don’t recall noticing the issue prior to the OS upgrade.

i’ll see how i go with it under Debian 12 over the weekend and probably re-upgrade to Debian 13 early next week to then see if the issue re-presents itself.
Interestingly, the calendar that contains the most events is the one that was listed in the pm2 logs when the host was issue under Debian 13.
Now that the system is back under Debian 12, I’ll recheck the logs to see if the same notification in the pm2 logs is listed.

One item i also noted in the pm2 logs was it identified that pm2 was out of date and i need to upgrade.
I’m not 100% sure, but I think my MM is currently on 6.0.6, and 6.0.13 is the latest stable version available.
I did attempt to upgrade pm2 from the instructions at pm2.io using “npm install pm2@latest -g” or “sudo npm install pm2@latest -g” and though it appeared to upgrade, it always returned an error that “-g” was an unknown command or option.
When i then run pm2 --version, it still reported that i was running 6.0.6.

@sdetweil
I restored my MM from an image i took of it from prior to upgrading to Debian 13 and, so far, I am not experiencing the same refresh.
I’ll keep an eye on things over the next few hours and see if the issue re-occurs.

@sdetweil
i forgot to mention that i experience the same constant refresh/reload issue on both the host and browser instances of the MM that displays the default calendar module, so i guess it’s not isolated to browser on my PC where I view both MM instances.

What would the command be that I need to run to view the npm output?

Thanks Sam.
I get the requested information later today and add it the conversation.

Just to clarify the “randomness” of the refresh that I am experiencing, the listing of the calendar events would temporarily disappear and reappear as would be expected with a refresh cycle, but it would do it repeatedly in quick succession/constantly do it.

I took a ~45sec video of the issue, but the video is 86MB and i was unable to upload.
Is there somewhere I can upload it to?

I run two instances of MM from the host - the first one is the primary instance, which is the one experiencing the issue. This is viewed directly on a monitor attached to the host.
The second instance is only viewable and viewed from a browser (Chrome) on my computer.

I also view the first instance on my computer via a second browser tab and use an Extension to switch/rotate between the two tabs on 5 min intervals. The extension does have an option to refresh/reload the next tab to be displayed but I have not enabled this feature, knowing that it would force a pull of the calendar.

My MMs start with the following commands :
pm2 start ~/MagicMirror/installers/pm2_MagicMirror1.json
pm2 start ~/MagicMirror/installers/pm2_MagicMirror2.json

{
  "apps" : [{
    "name"        : "MagicMirror1",
    "cwd"         : "/home/user",
    "script"      : "/home/user/MagicMirror/installers/mm1.sh",
    "watch"       : ["/home/user/MagicMirror/config/config1.js"]
  }]
}

{
  "apps" : [{
    "name"        : "MagicMirror2",
    "cwd"         : "/home/user",
    "script"      : "/home/user/MagicMirror/installers/mm2.sh",
    "watch"       : ["/home/user/MagicMirror/config/config2.js"]
  }]
}

The bash scripts referenced in the .json files above, are :

#!/bin/bash
cd /home/user/MagicMirror
export MM_CONFIG_FILE=config/config1.js
export MM_PORT=8081

if [ $(ps -ef | grep -v grep | grep -i -e xway -e labwc | wc -l) -ne 0 ]; then
   npm run start:wayland
else
   DISPLAY=:0 npm start
fi

#DISPLAY=:0 npm start

#!/bin/bash
cd /home/user/MagicMirror
export MM_CONFIG_FILE=config/config2.js
export MM_PORT=8082
npm run server

#DISPLAY=:0 npm start

I only experience the random/constant refresh issue with the first MM instance running the default Calendar module.
The second instance runs a different calendar module, MMM-MonthlyCalendar from kolbyjack, for a different Google Calendar that is not one of the four accessed by the first instance.

@sdetweil
Thanks Sam.
Here is my config for the default calendar module:

{
module: “calendar”,
header: “Upcoming Events”,
position: “top_left”,
config: {
maximumEntries: 10000, // 10
maximumNumberOfDays: 120, // 365 (30May25 - changed from 50)
pastDaysCount: 0, // 0
displaySymbol: true, // true
defaultSymbol: “calendar”, // calendar
showLocation: true, // false
maxTitleLength: 50, // 25
maxLocationTitleLength: 50, // 25
wrapEvents: true, // false
wrapLcoationEvents: false, // false
maxTitleLines: 3, // 3
maxEventTitleLines: 3, // 3
fetchInterval: 300000, // 300000 (5 minutes)
animationSpeed: 2000, // 2000 (2 seconds)
fade: false, // true
fadePoint: 0.25, // 0.25
tableClass: “small”, // small,xsmall, medium, large, xlarge
displayRepeatingCountTitle: false, // false
dateFormat: “MMM Do”, // MMM Do
dateEndFormat: “HH:mm”, // HH:mm
showEnd: true, // true
showEndsOnlyWithDuration: false, // false
fullDayEventDateFormat: “MMM Do”, // MMM Do
timeFormat: “relative”, // relative, absolute, dateheaders
getRelative: 6, // 6, 0=absolute
urgency: 7, // 7
broadcastEvents: true, // true
hidePrivate: false, // false
hideOngoing: false, // false
broadcastPastEvents: true, // false
sliceMultiDayEvents: false, // false
nextDaysRelative: false, // false
limitDays: 0, // 0
limitDaysNeverSkip: false, // false
flipDateHeaderTitle: false, // false=left, true=right
hideTime: false, // false
hideDuplicates: true, // true
showTimeToday: false, // false
coloredBorder: false, // false
coloredBackground: false, // false
updateOnFetch: true, // true
coloredText: false,
coloredSymbol: true,
customEvents: [
{keyword: ‘Birthday’, symbol: ‘cake’, color: ‘White’},
{keyword: ‘Greens’, symbol: ‘recycle’, color: ‘Orange’},
{keyword: ‘Recycling’, symbol: ‘recycle’, color: ‘Green’},
{keyword: “Anniversary”, symbol: ‘ring’, color: ‘Gold’},
],
tableClass: “xsmall”,
calendars: [
{
// Added : 26-Apr-23
color: “#8B0000”, // dark red
symbol: “users”,
url: ‘https://calendar.google.com/calendar/ical/user1/basic.ics’,
},
{
// Added : 26-Apr-23
color: “#00008B”, // dark blue
symbol: “male”,
url: ‘https://calendar.google.com/calendar/ical/user2/basic.ics’,
},
{
// Added : 26-Apr-23
color: “#A020F0”, // purple
symbol: “female”,
url: ‘https://calendar.google.com/calendar/ical/user3/basic.ics’,
},
{
// Added : 26-Apr-23
color: “#023020”, // green
symbol: “male”,
url: ‘https://calendar.google.com/calendar/ical/user4/basic.ics’,
},
]
}
},

The default Calendar module on my MM keeps randomly refreshing multiple times.
The issue started prior to the last MM update and I thought the issue would be fixed post upgrading to 2.33, but the module still does it.

My MM was also running on Debian12 on an Asus NUC and has worked without issue since the previous MM version.
With the issue continuing post 2.33, I thought i’d upgrade to Debian13, but the issue persists.

My config.js file has a fetchInterval value of 300000ms (5min) for the calendar module.

I took a video of showing the occurrence, but the file is too big to upload.

Would someone have any idea or an explanation as to why it would behave like this?

@sdetweil
it could, but to be honest I don’t know, as I installed it after changing to the xorg desktop

@sdetweil
I found a way to get MM working on Debian 12 without the use of the Wayland windowing system and steps you provided to get that working.

After initially provisioning the host with the OS, when I was prompted to login, I had to click the Gear icon and select the GNOME on Xorg option, then login as normal.
Once logged in and presented with the Desktop Overview, I enabled the Automatic Login option in Settings > Users.

I then installed the No Overview extension https://extensions.gnome.org/extension/4099/no-overview/ so the GNOME Desktop is displayed instead of the Desktop Overview view after logging in.
This also disables/turns off the Hot Corner and Active Screen Edges options in Settings > Multitasking > General

Installed MM via your script as normal and MM displayed immediately.

Other steps I took to configure the host were to set:
In Settings > Power

• Screen Blank = Never
• Automatic Suspend = Off

In Settings > Multitasking > Workspaces

• Selected Fixed number of workspaces
• Set Number of Workspaces = 1

The Overview view and all other GUI features of the host OS can still be accessed by hitting the Windows key on the keyboard.

Hope this helps others who may come across the same issue as I had if/when they upgrade their MM host to Debian 12 (or higher).

@sdetweil
I’ve decided to stick with Debian12 (v12.11.0) on my NUC and try to work this matter out as I really want to move on from the existing Debian11 NUC.

I have installed the OS with the vanilla settings added SSH Server, leaving the default Desktop Environments of Debian Desktop and GNOME Desktop selected.

After completion, I added the nominated user account to the sudo group and configured it in the DE to auto-login to circumvent being prompted to select a user and enter a password if/when the host is rebooted.
The Desktop loads and displayed as expected and does not show the Desktop Overview, as per your previous screenshot.

I installed MM via your script and updated npm to the latest version as indicated during the MM install process. MM still did not display. I also tried your updated mm.sh script without success.
I am also unable to view MM via a browser from another computer after setting ipWhitelist to [] (commented out the original) and restarting pm2.

Checking the pm2 error logs does indicate something to do with the Wayland platform :

0|MagicMirror  | [229988:0522/141042.895081:ERROR:wayland_connection.cc(199)] Failed to connect to Wayland display: No such file or directory (2)
0|MagicMirror  | [229988:0522/141042.895519:ERROR:ozone_platform_wayland.cc(276)] Failed to initialize Wayland platform
0|MagicMirror  | [229988:0522/141042.895701:ERROR:env.cc(257)] The platform failed to initialize.  Exiting.
0|MagicMirror  | /home/serveradmin/MagicMirror/node_modules/electron/dist/electron exited with signal SIGSEGV

@sdetweil
not working for me, even after following the steps you have detailed above.
When the computer boots, i still just get to the Desktop view where similar to your last image but MM still never displays.

I’m gonna stick with Debian 11 and on my old/original NUC instead of going to Debian 12 on my new NUC, unless you know where I can download the Debian 11 ISO (no longer available from the debian site) and I can install it on the new NUC.

@sdetweil
I also configured Debian to autologin as a given user account that I created during the installation process so I am not prompted to login after the computer reboots and it just goes straight to the Desktop.

@sdetweil
I re-installed Debian12 and left the default Desktop Environment selections of Debian and GNOME selected.
Pretty much the vanilla/default install.
Did you have to do anything regarding how, when the Debian is eventually displayed, that MM is shown automatically?
I can’t seem to get MM to show and even though pm2 is enabled and running, I am stuck at the Desktop view where the Activities Overview button is shown in the top-left corner.

If I can’t get around this, the alternative is to run it as a headless installation and just access MM via browser from other computers.

@sdetweil No, using the Debian .iso distro from the debian.org site.
I’m installing on a NUC, not a RasPi.

@sdetweil Thanks, so during the OS installation, when I get to the point where I am prompted to select and install software, I should just keep the default selected options of Debian desktop environment and GNOME?