Default Calendar module frequently refreshes

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.

sdetweil

@DarrenO-0 on the pm2 side there are two parts

the code on the disk
and the part running

to change the part running
you need to execute

sudo pm2 updatePM2

sdetweil

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

DarrenO 0

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

DarrenO 0

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

michaelarnauts

@sdetweil

That makes sense, but I see a lot more updates then what you describe here.
I’ve added a screenshot of the updates I get to my github issue, and I’ve added it here as well. (note that all the messages have the same length, and some are a few seconds apart.

I’m not sure how to proceed in troubleshooting. When I enable debug logging, it is outputting a LOT (the whole ics file contains data from years ago).

sdetweil

@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

sdetweil

@michaelarnauts For the log output, we were looking for the broadcasting xxxx events messages entries
But note they have the full URL string , which you shouldn’t post on the forum

DarrenO 0

@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

@DarrenO-0 weird!!!

DarrenO 0

@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

@DarrenO-0 in the output of npm start
There will be a line

Broadcasting xxx events for calendar yyyy
Where yyyy is the full url configured in the calendar

That line will have a timestamp at the beginning of the line

That is the output of the calendar module fetcher and starts the delivery to the front end to display

If you use pm2 that content is captured for you

You could use grep to extract just those lines

cd ~/.pm2/logs
ls

Find the right filename.
Pm2_app name-out.log

grep Broadcasting fffff
Where fffff is the file name you selected
Note the file is added to each time MagicMirror is restarted unless you clear it first
pm2 flush
To clear

Before posting in a public place, make sure to mangle the url on each line so as not to expose your working cal url