In one of our next versions the user will have the ability to set a “read only” on the client side. Maybe this helps with your use case 🙂
Duplicate calendar events
-
@cgogolin Looks good to me and I can’t see why this event is added again. However, I’d really need to look at the whole sync process. Maybe you can just replace all
SUMMARY
,LOCATION
,DESCRIPTION
,DTSTART
,DTEND
values withXXX
to anonymize it and send it to play@bitfire.at? -
@rfc2822 The problem is that many of these fields have values that extend over several lines. For the fields you mentioned I can remove with emacs
regexp-replace
and regular experssions of the typeDESCRIPTION:.*\( .*\)*
because all the following lines start in with a white space. But the descriptions also appear in lines such as
2017-08-28 11:52:51 1809 [ical4android.AndroidEvent] Built event object PARAMETER #0 = mType: 1, mUri: content://com.android.calendar/events?account_name=xxx%40xxx.net[...]description=THE DESCRIPTION HERE EXTENDS OVER SEVERAL LINES title=[...]
Here I get a “Stack overflow in regexp matcher” if I try to match them with a regexp of the type
description=\(?:.\| \)+title=
I know I am asking for much, but do you have any idea how to remove them? At the same time it is not really my fault that the logs are printed in a format that is so difficult o annonymize…
-
I used grep to extract all lines that contain the string
b133303f-f0d2-4cc9-a89b-cf4a49f5e003.ics
fromdavdroid-26476-20170828-114615.txt
. Maybe that contains already enough information for you to see what is going on? 0_1503928139665_davdroid-26476-20170828-114615.txt.greped -
@cgogolin No, I’d need the context. It’s already hard enough to look through real logs, but only a few grepped lines for a bug that I can’t reproduce … maybe we can wait until this problem occurs more often so that it can finally be reproduced.
-
In the end I removed all the
title=
anddescription=
parts manually. I just sent you the file via email to play@bitfire.at. Hope you will see something in there… -
@cgogolin Thanks for the logs. Unfortunately, I just can see that at some time, there are some new entries which appear on the server (e.g.
https://xxx.xxx.org:8080/owncloud/remote.php/dav/calendars/user1/username2_username1_shared_by_user2/540c319d-3a76-4726-a013-b2b479220051.ics
) and then are downloaded and added to the calendar by DAVdroid. Don’t know if those events are the “duplicated” ones or just newly added events, but the whole DAVdroid processing seems correct to me.Maybe it’s related to the shared calendars… are you using the latest version of OwnCloud and it’s calendar app?
-
Thanks for your analysis. The entry
540c319d-3a76-4726-a013-b2b479220051.ics
you mention is in the database dump only once and appears asINSERT INTO "Events" VALUES(3135,'540c319d-3a76-4726-a013-b2b479220051.ics',0,NULL,0,12,'XXX ',NULL,NULL,NULL,NULL,1,0,1506272400000,1506286800000,'Europe/Madrid',NULL,0,0,0,1,0,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,1506286800000,1,0,1,1,'xxx@xxx.net',NULL,0,'Europe/Madrid',NULL,NULL,'540c319d-3a76-4726-a013-b2b479220051','f006d92e71f6a52db9ec59b99089428a',NULL,'0',NULL,NULL,NULL,NULL,NULL,NULL,NULL);
on the contrary, the duplicate entry I described above
b133303f-f0d2-4cc9-a89b-cf4a49f5e003
is not among those that appear after aNew resources have been found on the server
entry in the log file. I don’t know where theseNew resources
come from, but I would conjecture that they have nothing to do with the duplicate entry issue.The shared calendar was just an example. The same thing happens also for calendars only synced between the phone, ownclound, and thunderbird/lightning with sogo connector. I am using an up-to-date owncloud. Since the dav backend has been moved into the core I am no longer using the calendar app there.
I have now also verified that the duplicate entries are only once in the owncloud database, which also explains why they only appear once in thunderbird and on the other phone that syncs the very same shared calendar via a different owncloud account. This is also consistent with the fact that every time I do a re-sync (with the procedure described above) other entries end up appearing twice. As a side remark: I have never seen an entry more than once.
To me it really looks like a problem between davdroid and the android calendar database.
-
@cgogolin Well as I see it, DAVdroid doesn’t insert those events, so maybe something else inserts them. This could explain why it’s not reproducible here… Are there any other apps installed which could edit/insert events?
If you have another suggestion on what I could do, please let me know.
-
I just checked with https://play.google.com/store/apps/details?id=org.androidsoft.app.permission which apps have calendar read or write permissions. These are: DAVdroid, Tasker, and Signal. All three are also installed on the other device that does not show the duplicate entries. Tasker has a few profiles to switch wifi on and off, but nothing with relation to calendar entries. I really don’t understand what is going on… This is one of the issues I wouldn’t even have dared to report, but then I saw that some else had the same problem so I had hope I could help resolve it…
If you have any suggestions for what I can do, please let me know. I keep you posted in case we observe anything else that might be useful for you. -
The last DAVdroid update on Google Play states under WHAT’S NEW
prevent multiple syncs to be run at the same time for the same account and authority (hopefully fixes duplicate entries – if you have duplicate entries, please uninstall DAVdroid and try with 1.9.1 again)
and indeed, the problems reported above seem to have disappeared after I uninstalled and reinstalled the new version. Thanks for fixing it and making this App even more awesome!