Bug 254742 - getting a conflict for all appointments on the first sync
Summary: getting a conflict for all appointments on the first sync
Status: VERIFIED WORKSFORME
Alias: None
Product: KOrganizer Mobile
Classification: Applications
Component: calendar (show other bugs)
Version: unspecified
Platform: Maemo 5 Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-20 10:19 UTC by Bernhard E. Reiter
Modified: 2011-02-15 18:09 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard E. Reiter 2010-10-20 10:19:14 UTC
N900 Kontact Mobile Mail, Version 20101015-1
because it happened to me twice now:
Under some conditions on the initial syncs, before I can see
any calender entry, I am getting a conflict for each appointment
in a new calender folder.

Seen with 20101008 on an folder older. 
And now seen with 20101015-1 on a folder I've configure for the first time.

As I need to handle each dialog separately with several hundereds of events, because of #250570 (Conflict dialog is not readable) I had to kill my akonadi
to get a workable phone again, which makes this critical.
Comment 1 Volker Krause 2010-10-21 08:41:07 UTC
Is this limited to some folders or does this happen for each and every appointment? If the first, does the folder contain duplicated mails (they could trigger the conflict)?
Comment 2 Bernhard E. Reiter 2010-10-21 09:55:08 UTC
I cannot say if this is limited to some folders, it might be.
The folder I got it now has 320 entries, I cannot manually go through them
to check if I get conflicts in another folder.
The same folder is used by myself with e35 and e4 desktop client, which
I would expect to flag any real conflict there is. So I am 99% sure this 
is an artifact of Kontact Mobile.

Of course it is not know if there are double emails in the local cache
(aka akonadi). I can try and check this with akonadi-console.
Comment 3 Volker Krause 2010-10-22 14:44:56 UTC
You should be able to easily check for duplicated mails with one of the desktop clients (sort by subject), the total number of duplicates should be comparable to the number of conflicts you got. So even a very quick check should easily find them if I'm on the right track here, if not obviously something else is causing this.
Comment 4 Bernhard E. Reiter 2010-10-22 15:01:34 UTC
Do doublicates in the folder that I could see with my e35 client.
Comment 5 Bernhard E. Reiter 2010-10-26 14:16:21 UTC
It does not seem to happen everytime. I could get a calender
synced with a a fresh configuration and using offline mode with

Package: kdepim-mobile
Version: 4:4.6~20101025.1189542-1maemo2.1188357
Package: libqt4-experimental-gui
Version: 4.7.0~git20100908-0maemo1
Comment 6 Sergio Martins 2010-11-19 14:02:42 UTC
SVN commit 1198720 by smartins:

Print ids of conflicting items so i can easily find them in akonadiconsole.

CCBUG: 254742

 M  +1 -0      libkdepim-copy/kincidencechooser.cpp  
 M  +6 -0      resources/kolabproxy/incidencehandler.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1198720
Comment 7 Sergio Martins 2010-11-19 15:07:53 UTC
Bernhard,

In your akonadiserver's output log you should have something like:

akonadi_kolabproxy_resource(23418) IncidenceHandler::translateItems: Conflict detected for incidence uid   "libkcal-600132418.938"  for imap item id =  6961  and the other imap item id is  6913

So manually run: akonadictl start &> akonadi.log

then when you get the conflict dialog:
grep Conflict akonadi.log

it should tell you which e-mails are duplicated.
Comment 8 Bernhard E. Reiter 2010-11-23 12:55:28 UTC
Sergio, thanks for responding.
I still do not know what triggered this, but it had not happend to me for a while. (Thus downgrading priority and severity.)

Package: kdepim-mobile
Version: 4:4.6~20101115.1197307-1maemo3.1196115
Package: libqt4-experimental-gui
Version: 4.7.0~git20101111-0maemo1

Thanks for your change, I believe it will make future analysis easier,
which is important. (When I was seeing the issue, there were no obvious duplicates.)
Comment 9 Andre Heinecke 2011-02-15 18:09:53 UTC
Moving this from resolved to verified -> worksforme since there are no reports of this happening again in the last 4 months. But since there can be no concrete fix named -> worksforme.