GNOME Bugzilla – Bug 613803
CalDAV calendars (tasks, memos) not refreshed
Last modified: 2010-03-30 21:38:01 UTC
I have calendar, tasks and memo's on a remote Caldav server. Running Evolution 2.28.2 from multiple computers (i.e. office and home through vpn, I would say a typical use case), the local cache for the calendar, tasks and memo's do not get synched. Looking on the caldav server, new tasks/meetings/memo's *are* added. Deleting the ~user/.evolution/cache/calendar and tasks folder with evo shutdown (including evolution-data-server !!) and restarting forces a new download of calendar and tasks. This problem has also been reported on: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559177. Note 1: information appears to be cached regardless the setting of 'make available for offline use'. Note 2: that it normally does not take long to download this Caldav information, so the only use of the cache would be in offline operation. However with the vpn not up, you can not use the calendar, even with 'offline use' set. Ferry
Thanks for a bug report. (In reply to comment #0) > Running Evolution 2.28.2 from multiple computers (i.e. office and home through > vpn, I would say a typical use case), the local cache for the calendar, tasks > and memo's do not get synched. Looking on the caldav server, new > tasks/meetings/memo's *are* added. It doesn't listen for any change in the cache, there is no such function available for CalDAV, so it does periodical pings on the server to see whether anything changed. See your Refresh interval in the calendar/task/memo properties dialog. Since 2.30 you can also force it refresh, with a popup menu item. > Note 1: information appears to be cached regardless the setting of 'make > available for offline use'. Yes, it fetches everything, but only for quicker response on any view requests. > Note 2: that it normally does not take long to download this Caldav > information, so the only use of the cache would be in offline operation. > However with the vpn not up, you can not use the calendar, even with 'offline > use' set. When it's downloading for the first time, then it fetches really everything, but when it's downloading the next time, then it's comparing against local cache and fetches only changed/new items from the server. The offline mode for CalDAV is not working, and a bug request exists for it. I recommend to try 2.30.0 when it's out, as there had been some improvements done within 2.29 development cycle. But before it's out and available, could you try to look on the Refresh setting, please? Also, you can close Evolution, and also evolution-data-server, and next start will be done a refresh of the cache automatically.
Milan, I don't know what you mean by "doesn't listen for any change in the cache". The cache is local, evo knows what is in its cache. It just doesn't know if there is a change on the server. This works: - When I add an appointment or task it is added to my local cache and uploaded to the server. This not: On the other machine the new appointment or task is *never* downloaded. Not even after a reboot. The Refresh interval is set to 30 minutes in all cases. This is exactly the bug: the local cache is never refreshed, no matter how long you wait. And believe me, I've waited way longer then 30 minutes. As you state, close evo and eds, then restart evo, should refresh the cache - this does not work. Actually I close evolution-alarm-notify as well. The only way to get the cache 'refreshed' is to close evo and eds, delete the local cache ~/.evolution/cache, then restart evo. This is exactly the same problem as reported on debian by Roland Mas. I know that 2.30 is on its way, I just want to make sure this bug gets fixed in 2.30. The whole purpose of having appointments/tasks on a server is to be able to read them from a remote client, and as it is that does not work. With imap, ldap (yes I can add/edit remote contacts through evo) and caldav working already, I believe we have a better setup then MS Outlook. And no other client I know of can handle all these things. If only I could stop evo from caching, or get it to really refresh the cache. Ferry
(In reply to comment #2) > I don't know what you mean by "doesn't listen for any change in the cache". Ouch, I'm sorry for a confusion, that's a typo, it was supposed to be "on the server", not "in the cache". What is your server, please? And if I understand you correctly, then you are adding events from evo on both machines, right? Could you try this, please: a) close evolution on machine 1 b) then run on machine 1: evolution --force-shutdown c) add an event on machine 2 d) on machine 1 run eds as this: $ CALDAV_DEBUG=all /usr/libexec/evolution-data-server-2.28 &>eds.log e) then on another console on machine 1 run evolution f) see the eds.log file, where should be shown all the communication between evolution and your server, telling you what it found, what it did with it and so on. Maybe something useful will be there. You know, your scenario works fine for me with DAViCal server.
Our server is fairly up-to-date Debian Squeeze, with slapd, uw-imapd from the repositories, and DAViCal 0.9.6.1 not from the repositories (for historic reasons). I know you find my bug report hard to believe. So have done exactly what you asked above, except for the code as evolution-data-server-2.28 can be found in /usr/lib/evolution and /usr/libexec does not exist here. Here are the exact steps: 1) delete the cach on both machines 2) start evo on 1, wait until davical info is downloaded, evolution --force-shutdown 3) start evo on 2, wait until davical info is downloaded, evolution --force-shutdown ** the caches should now be equal 4) start evo on 1, delete 1 appointment, task and memo, add 1 new appointment, task and memo, evolution --force-shutdown 5) CALDAV_DEBUG=all /usr/lib/evolution/evolution-data-server-2.28 & eds.log, send to bg, start evo ** nothing appears to be updated 6) save eds.log as eds-before-del.log 7) evolution --force-shutdown, del ~ferry/.evolution/cache, CALDAV_DEBUG=all /usr/lib/evolution/evolution-data-server-2.28 & eds.log, send to bg, start evo ** all changes appear updated 8) save eds.log as eds-after-del.log The logs do no tell me much, I see in the before log that thing should be refreshed, but not in evo itself. Attachments follow Ferry
Created attachment 157114 [details] eds.log before deleting the cache
Created attachment 157115 [details] eds.log after deleting the cache
Eh, step 5 08 are on machine 2. Ferry
s/5 08/5 - 8/
Works like a charm with DAViCal 0.9.7.6-0 and git master Evolution (~2.30.0), though the CalDAV part is pretty the same as in Evolution 2.28.3 or so. I would suggest you to update your DAViCal server to the latest, though that mine is about 5 months old too.
We yesterday updated Davical to 0.9.7.6 from Debian Squeeze, no effect on the bug reported here. Looking at my own 'eds.log before deleting the cache' I see mentions of 'CalDAV - finished syncing with 11 items in a cache'. But still my calendar is not updated. What do I need to do to get my calender synced then? Ferry
Oops correction. Updating Davical to 0.9.7.6 currently in Debian Squeeze definitely solves this problem. I needed to give evo a few minutes to sync. My apologies for the confusion. This can be closed. Thanks, Ferry
Good, you scared me a bit, I was quite out of idea, just sending here a long comment with summarization of what we did and what we didn't and what we can do. Nice it works.
Yes, sorry. Actually it is the 2nd time I thought the problem to be in evo, while it was actually in davical. I will take care next time. At least I am very happy now, and hopefully Roland Mas (bugs.debian) as well. Thanks again, Ferry
(In reply to comment #13) > Yes, sorry. That's OK, I'm happy we found a solution. > Actually it is the 2nd time I thought the problem to be in evo, while it was > actually in davical. I will take care next time. I've pretty good experience with DAViCal myself, while using it for testing with CalDAV in Evolution. Usually something works fine in DAViCal, but doesn't on other server.