After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 360517 - Birthday events disappear from the calendar
Birthday events disappear from the calendar
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Calendar
2.28.x (obsolete)
Other All
: Normal major
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
: 432188 503196 547949 565361 569232 582628 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-10-07 22:48 UTC by Porges
Modified: 2011-01-14 14:31 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28



Description Porges 2006-10-07 22:48:18 UTC
Please describe the problem:
Birthday events for people disappear from the calendar (I think upon each restart, but I'm not sure). Re-saving the contact makes it appear on the calendar again. Manifests itself both on the internal Evolution calendar and the Gnome calendar applet.

Steps to reproduce:
1. Create a new contact with a birthday. The birthday shows up on the calendar.
2. Restart the computer (possibly another way to do this step).
3. Birthday no longer on calender.

4. Editing contact (even just adding a space and removing it from one of the fields so you can re-save it) puts the birthday back onto the calendar.


Actual results:
As stated.

Expected results:
The birthdays to not disappear from the calendar.

Does this happen every time?
Yes.

Other information:
Running under Ubuntu Edgy.
Comment 1 Kurt McKee 2008-05-09 02:16:20 UTC
I'm seeing this on Ubuntu Hardy. I don't need to restart; I just log out of X and log back in.
Comment 2 Akhil Laddha 2008-08-06 06:10:30 UTC
It works fine in 2.23.6.
Are you sure birthday calendar is enabled after restart ? 
can you please check in current stable 2.22.3, thanks in advance.
Comment 3 Kurt McKee 2008-08-06 13:58:27 UTC
It's not working fine in 2.22.3.1. There are a total of 12 people whose birthdays Evolution now shows in calendars. The other 300 people with birthdays in my address book are not shown. For instance, I know three people whose birthdays are on October 14th, and another three whose birthdays are on August 2nd, but none of them are shown.
Comment 4 Akhil Laddha 2008-09-08 11:09:38 UTC
changing product version as per comment#3
Comment 5 Don Pellegrino 2009-07-07 19:39:11 UTC
I am also seeing this behavior with Evolution 2.26.2 on Debian.
Comment 6 Milan Crha 2009-07-08 10:57:48 UTC
*** Bug 565361 has been marked as a duplicate of this bug. ***
Comment 7 Milan Crha 2009-07-20 13:53:53 UTC
*** Bug 432188 has been marked as a duplicate of this bug. ***
Comment 8 Milan Crha 2009-07-20 13:56:28 UTC
*** Bug 503196 has been marked as a duplicate of this bug. ***
Comment 9 Milan Crha 2009-07-20 13:57:13 UTC
*** Bug 547949 has been marked as a duplicate of this bug. ***
Comment 10 Milan Crha 2009-07-20 14:01:07 UTC
*** Bug 582628 has been marked as a duplicate of this bug. ***
Comment 11 Milan Crha 2009-07-20 14:52:35 UTC
Just a little update from the duplicates:
a) It seems to be related on the contact size. For example large contacts, with
   assigned image, might trigger this
b) it was seen also with address book with quite many contacts.
c) last time I was investigating this, I remember seeing it with contacts as
   in a), though not always. What I recall from the investigation the address
   book backend was sending all the contacts through the ORBit, but not all
   of them were received in the calendar. I didn't get why that time. Let's
   see how this will work in eds-dbus (either same, thus not ORBit related,
   or better).
d) One report mentioned some relation ship between components without DTSTART,
   but I doubt it's our case, because created events in the contacts backend
   has this always set. Thus I think this comes from a local calendar,
   which is marked for alarm notifications.
Comment 12 Andri Möll 2009-07-23 13:35:07 UTC
I can confirm that removing all of the pictures on contacts and restarting Evolution 2.26.3 (incl. data server) solves this.  Weird bug from the user's perspective.
Comment 13 Petr Pluhacek 2009-12-04 17:20:16 UTC
Problem seems to be still valid. I can't confirm, this bug is related to contact size. I have never used contacts with attached images, but this problem appeared.
Evolution 2.28.1
Comment 14 Milan Crha 2010-03-25 11:46:59 UTC
Could anyone of you retest this with an upcoming Evolution 2.30.0+, please? All the related bits in the background were changed from ORBit/Corba to DBus, thus if we reached some limits on Corba, then they do not apply on DBus, hopefully. As far as I can tell, I can see my Birthday contacts in the Calendar, but I do not have any real data here, so having a confirmation from anyone seeing it would be the best thing. Thanks in advance.
Comment 15 Andri Möll 2010-03-25 12:51:35 UTC
(In reply to comment #14)
> Could anyone of you retest this with an upcoming Evolution 2.30.0+, please? All
> the related bits in the background were changed from ORBit/Corba to DBus, thus
> if we reached some limits on Corba, then they do not apply on DBus, hopefully.
> As far as I can tell, I can see my Birthday contacts in the Calendar, but I do
> not have any real data here, so having a confirmation from anyone seeing it
> would be the best thing. Thanks in advance.

I'm not yet on ver 2.30 to confirm, but as far as I remember the workaround *was* related to reducing contacts' size.  Put a few meg picture on your birthday children and see if it still works.  Though last time even a few hundred kB broke Evolution.
Comment 16 John Keller 2010-04-11 08:20:42 UTC
I have a lot of birthdays in my contact, which broke in the calendar before. Some would appear/disappear randomly.

In 2.30.0.1 (Mandriva Cooker 2010.1), this *appears* to be fixed.

I emphasize "appears", because it seemed to be fixed in a previous version of Evolution, but then reappeared. I'm not sure if that's because A) I tried the contacts in a fresh install (migrate just Evo data to new account, tested OK; later migrate my whole home directory, and it broke) or B) I only checked for some contacts' birthdays (with a few hundred birthdays, until I actually run into one that's missing in the course of the year it's hard to know for sure).


On a slightly related note, birthdays now appear at 2:00 AM instead of midnight every day! Sigh, once again one bug is (potentially) squished and another regression pops up... I see this is in bug 611646, I'll report there.
Comment 17 Tobias Mueller 2010-05-27 15:55:18 UTC
Andri, it'd be nice if you could confirm that it disappeared with a more recent Evolution version. I'd close as OBSOLETE if nobody claims this issue to be present in Evolution 2.30.
Comment 18 Andri Möll 2010-05-27 16:15:45 UTC
Tobias, unfortunately my distro's not yet on 2.30. I'd perhaps go with John's confirmation in comment #16. Should the issue reappear, we'll reopen this.
Comment 19 Tobias Mueller 2010-05-27 20:03:47 UTC
*** Bug 569232 has been marked as a duplicate of this bug. ***
Comment 20 Akhil Laddha 2010-07-10 04:23:03 UTC
Please feel free to reopen the bug if the problem still occurs with a newer
version of GNOME 2.30.2 or later, thanks.
Comment 21 Milan Crha 2010-08-24 12:22:30 UTC
Also possible that some contacts may wait in a pending notification cache, thus the contacts calendar backend didn't receive an information about them, which was just fixed in bug #625115, and will be part of 2.32.0. But it's just a wild guess.
Comment 22 mark.vanrossum 2011-01-14 14:06:46 UTC
This bug has reappeared for me in FC14.
Can it be re-opened?

I'm using:
evolution-2.32.1-1.fc14.i686
evolution-data-server-2.32.1-2.fc14.i686

How can I debug it further?
Comment 23 John Keller 2011-01-14 14:31:12 UTC
(In reply to comment #22)
> This bug has reappeared for me in FC14.
> Can it be re-opened?
> 
> I'm using:
> evolution-2.32.1-1.fc14.i686
> evolution-data-server-2.32.1-2.fc14.i686
> 
> How can I debug it further?

It seems to be a different bug, see bug 636334