Default Calendar module frequently refreshes

DarrenO 0

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

@DarrenO-0 can you post the config for calendar, xxx out your urld

DarrenO 0

@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’,
},
]
}
},

sdetweil

@DarrenO-0 also can you look at the output of npm start or however you start MagicMirror
And find the messages

Broadcasting xxx messages for url xxxx

Collect 15 of those messages either the timestamp
Xxx out the url string, or match them to your 4 utls
These messages should be on the fetchInterval time cycle

Each url fetch is done separately, and they contribute to the shown list of events immediately , which may cause a visual flash

Looking at the code, it uses fixed timers which is restarted for the next cycle after processing this cycle. So that means longer/larger calendar lists will take longer than shorter ones. This will cause the fetch cycles to drift apart and constantly change
I’m guessing is this is the randomness

The log messages should show consistent cycle times for an individual url, but varying separation between url fetches
If your system is low on memory and utilizes swap on an sd card this could also affect processing time for larger calendar memory requirements, causing additional drift

DarrenO 0

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

@DarrenO-0 the calendar fetch is done on the server side,
All browsers access that same data

sdetweil

@DarrenO-0 those calendar modules fetch the days themselves in their own way

DarrenO 0

@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?

sdetweil

@DarrenO-0 as MagicMirror is started by pm2 the command would be

pm2 logs —lines=xxxx

Two dashes in front of lines
Where xxxx is the number of most recent lines of output, default 15

You can also examine the files the logs are collected in,
In the ~/.pm2/logs. Folder, notice the . in front of pm2

The fact that you see it on other browsers confirms to
Me that this is fetch timing cycle related.
If you look at both displays at once, my guess is the refresh at the same time

DarrenO 0

@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.