Default Calendar module frequently refreshes

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.

sdetweil

@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

michaelarnauts

I just made this github issue to track this issue.

https://github.com/MagicMirrorOrg/MagicMirror/issues/3971

sdetweil

@michaelarnauts I replied to it, but there you have a different complaint.

The system design is
Pull the iCal file via the URL
It’s whatever events the source calendar wants to send , we have no control , it’s all text

We convert that to a usable list
And then figure out the repeating events and get a list that could be displayed, expired and not , as of right this second

Then we send that list out to other modules to use
MMM-CalendarExt3 for example, which displays a wall cal view, using the events in view expired or not

Then we process the not expired list and display the xx that you wanted

And repeat that whole process for the next fetchInterval
Once every xx minutes or whatever you have it set to

For each URL configured , we do the exact same process, each sending events when they are fetched. One URL processor doesn’t know about the next, they ALL run independently

DarrenO 0

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