MagicMirror
MagicMirror copied to clipboard
Problem with "broadcastPastEvents: true"
Hello I relatively new in MM, but I think I found a bug in it.
The "broadcastPastEvents: true" does not work, moreover, if I apply this configuration item to any (sub)calendar, this calendar is no longer broadcasted. If it omitted, or set to false, the calendar entries appear again.
I'm just test the MM in a Windows10 environment with the modules: updatenotification, clock, weather (current and forecast), calendar (my 6 Googel calendars), MMM-CalendarExt3Agenda, comliments. Later it will be installad in RPi.
All configurations tried so far work fine except the one mentioned.
Thank you for your attention. Kovaccsaba
can u show the calendar config from config.js.
remove the text for the url..
Yes, here it is:
ok, this is a bug I introduced in 2.20 . fixed in the next version
you can test the new version see https://forum.magicmirror.builders/topic/14327/testing-new-fixes-or-solving-current-problems-with-next-release-code
Sorry, but doesn't succeded!
After your suggested trial, I no longer have weather and MMM-CalendarExt3Agenda modules. :-(
so, you have local changes.. cause u changed package.json you should not be running under min, just normal windows terminal (cmd.exe)
git diff (should only be the "start", line) (save that line of text)
git checkout package.json to restore the original
then do the checkout develop and then npm install (as normal)
no reason those others should fail... that I am aware of
what do the startup messages say?
Thanks, but I reinstall the whole MM. I would wait to next published version insted.
When broadcastPastEvents is set to true, the list of events in the calendarutils.filterEvents method fill up with events that may be outside of the range of the current view (say when the list of events is being used to display for a monthly calendar and not an agenda).
When splicing the newEvents array without taking into context the interested date range, events are left off from the calendar view, making it look like the events data never loads. When in reality you get a list of 10 events (using the default value) that are from ages ago. This is especially true when you have a bunch of recurring events in your calendar. This was easily duplicated when you look at other modules that leverage the data gathering done by the default calendar module like the MMM-CalendarExt3 module. The default calendar module will show an agenda list, but the MMM-CalendarExt3 module will show a month view.
I think the idea introduced in https://github.com/MichMich/MagicMirror/issues/2868 is correct, but may need to be done in a different place. Somewhere you can take into account the interested date range maybe? Still trying to find a place in the code that this can be done, and if I can I'll submit a PR.
there are more than two issues.. collecting events and having past events in the collection
then broadcasting all that to other modules, and using it in the calendar module.
the calendar module does not show past events. but used to 'assume' that the collection ONLY contained future events. broadcast is unknown to the calendar formatter, but broadcast only works in the web component.. so the fetechers results HAVE to include the past events, so they can be broadcast,
and then the past events have to be discarded
and the max events per cal have to be applied to make the current list. sorted, and then clipped again by the total max events, AND then displayed..
it's quite a dance
This is my wish: "the calendar module does not show past events. but used to 'assume' that the collection ONLY contained future events. broadcast is unknown to the calendar formatter, but broadcast only works in the web component.. "
I suppose the web component is: modul:MMM-CalendarExt3 and modul:MMM-CalendarExt3Agenda
I hope we would be very happy if you could solve it :-) Thx!
When broadcastPastEvents is set to true, the list of events in the calendarutils.filterEvents method fill up with events that may be outside of the range of the current view (say when the list of events is being used to display for a monthly calendar and not an agenda).
When splicing the newEvents array without taking into context the interested date range, events are left off from the calendar view, making it look like the events data never loads. When in reality you get a list of 10 events (using the default value) that are from ages ago. This is especially true when you have a bunch of recurring events in your calendar. This was easily duplicated when you look at other modules that leverage the data gathering done by the default calendar module like the MMM-CalendarExt3 module. The default calendar module will show an agenda list, but the MMM-CalendarExt3 module will show a month view.
I think the idea introduced in #2868 is correct, but may need to be done in a different place. Somewhere you can take into account the interested date range maybe? Still trying to find a place in the code that this can be done, and if I can I'll submit a PR.
I'm only interested in those past events whose dates are above those to be displayed. The startDayIndex determines the starting date. If it 0, I don't want to see past events. Ok? It's important for me the past events in the actual date (today the not whole day events!)
no a module is made from 2 components
the web component, modulename.js and an optional node_helper.js , which does processing that is not allowed inside a browser. ( read file, access hardware..)
so calendar.js can send the broadcast but the fetcher, runs from the node helper.
so the fetechers gets all the info, including past events if requested, and sends it up to calendar.js.. which then broadcasts it for other module consumption ( calendar-ext3 for example), and then calendar.js does the formatting and display for the default calendar. which does not display past events.
the default calendar module doesn't know 'view' or 'agenda'. those are calext3 concepts.
the request is broadcast past events yes or no. if yes we look back a year, and forward a year.
then some other module will decide what part of that range to display.
calext3:has decided to use the broadcast data instead of having to read and process the calendar ics data directly.
So looking to understand the code a little more I don't think there is a bug here. I think it's purely a configuration issue. @kovaccs if you change the maximumNumberOfDays from 365 to something more suitable for your need (like 30 for a month view, or 7 for a weekly view) you will see data as you were expecting.
The only change I could possibly see that would be beneficial would be to change the default value of maximumNumberOfDays from 365 to maybe 30? This would prevent beginners (like myself) from thinking there is something wrong when trying to load other modules (MMM-CalendarExt3) and not seeing data.
So looking to understand the code a little more I don't think there is a bug here. I think it's purely a configuration issue. @kovaccs if you change the maximumNumberOfDays from 365 to something more suitable for your need (like 30 for a month view, or 7 for a weekly view) you will see data as you were expecting.
The only change I could possibly see that would be beneficial would be to change the default value of maximumNumberOfDays from 365 to maybe 30? This would prevent beginners (like myself) from thinking there is something wrong when trying to load other modules (MMM-CalendarExt3) and not seeing data.
Oh, that sounds like a useful suggestion! I'll try, I'm also a beginner MM user. ;-)
@wszeliga with broadcast:true, the other modules should get flooded w data. (default 2 years). so they should be able to pluck out whatever they need
one step forward! The maximumNumberOfDays set to 31, the specified calendar does not disappear when the broadcastPastEvents: true is specified, but past events are still not visible in MMM-CalendarExt3Agenda modul output.
So I think if you are having problems with a specific module (MMM-CalendarExt3Agenda in this case) you'd probably get more knowledgeable support opening an issue in that specific module's github. The maintainers here probably aren't as familiar with that 3rd party module as they are with the calendar module.
we should be able t close this now