Thanks for reporting!
It's the first time in the history of Remimderfox such a question arose,
never heard or recognized a problem like "memory leak". Also I have to
admit it's unknown to me about tests that have been done on this. Maybe
Tom can comment on it.
One point catches my attention:
> Is keeping birthdays with their original birthdate a problem (since there are so many virtual timepoints generated)?
A birthday is a one day event! And normally that event is entered with a
"yearly" repeat. This will generate one and only one event which is
spanning for one and only one day. Not more!
But we have seen users which entered the birthday at it's origin date
and defined that as starting day, and think this way: I have to see that
event all over the years, so they entered a ending date of eg. some
where in future, say year 2020. That way the user generates an event
lasting form the birthday (assume an example of 9.Jan.1990) == start day
until 9.Jan2020 == end date. With repeating yearly you generate one
events lasting 30years = 30*365 entries!!! That will blow up your stack!
And doing that with multiple/different birthdays you end up with huge
huge ICS data file which not only has to be stored, loaded into memory
and needs to get processed.
Also there is the problem with "overlapping" events. That is an event
lasts long that it's repeating period. For that the RmFX logic warns
with a popup, so I expect it's not the case. Maybe you have those
definitions in the past, but for the dialog will not popup, sorry didn't
tested for that.
Sounds a bit with what is in your ICS data?
Also I recommend to backup your ICS file and delete old years events
from the ICS file you actually work with.
Guenter