Thanks for the information and update! Great that you found it out.
Sorry for the inconvenience. Now we know that no_script prevents the usage of the forum. We’ll have a look at it.
I’d really appreciate any feedback. Many thanks in advance!
@meiser Do you use the latest ICSdroid version? The detection of multiple parallel syncs started by Android is available since ICSdroid a few versions.
Otherwise, I’d need to be able to reproduce the problem so that I can have a look. We don’t have duplicated events on our own devices and there are no other reports about that problem.
@rfc2822 Yes, I’m running the lastest ICSdroid version. I’m not sure how I can narrow it down as I can’t find the real precondition that triggers the duplicates.
@rfc2822 Could you maybe provide a debugging version which saves all logs to the internal memory (e.g. /sdcard) so that we can narrow down the issue? It happened again, but I can’t find anything in “logcat”.
@meiser At the moment, I do not have time for that Can you try with
setprop log.tag.icsdroid VERBOSE setprop log.tag.ical4android VERBOSE
on the device before logcat (
adb shell, then the two
I also see this issue. I am accessing ICS feeds served by posteo.de.
I am on current version 1.5.7, and I have now deleted and re-entered the feeds in ICSdroid, to find out whether this makes the issue disappear permanently.
I think recently the duplicates started to appear after an ICSdroid error message, saying that it could not connect to the server. Perhaps this observation helps to reproduce the issue? I will make a screenshot if this error happens again.
@jondo Are those public feeds? Can you provide the URLs? But I doubt that it’s related to the feeds itself… which device do you have? Which Android version?
@rfc2822 I have got a Samsung Galaxy S5 (SM-G900F), currently on Android 8.1.0 (LineageOS) without Google apps. I also saw the issue on Android 7 and on a Google Pixel with some stock Android 8.
I have now set up a test URL: https://posteo.de/calendars/ics/4cp77y98svfsg432i7mvwk7ck857fzqu . This contains a single event “ICSdroid-test”, on 2018-12-31. I will tell you when I notice it showing the issue.
@jondo Ok, thanks. I’ll subscribe to this feed, to.
Hi, it happened again. I could find this exception in the logcat.
[08-19 07:01:07.467 13158:13158 E/ActivityThread] Service at.bitfire.icsdroid.SyncAdapterService has leaked ServiceConnection at.bitfire.cert4android.CustomCertManager$1@2bfa043 that was originally bound here android.app.ServiceConnectionLeaked: Service at.bitfire.icsdroid.SyncAdapterService has leaked ServiceConnection at.bitfire.cert4android.CustomCertManager$1@2bfa043 that was originally bound here at android.app.LoadedApk$ServiceDispatcher.<init>(LoadedApk.java:1336) at android.app.LoadedApk.getServiceDispatcher(LoadedApk.java:1231) at android.app.ContextImpl.bindServiceCommon(ContextImpl.java:1450) at android.app.ContextImpl.bindService(ContextImpl.java:1422) at android.content.ContextWrapper.bindService(ContextWrapper.java:636) at at.bitfire.cert4android.CustomCertManager.<init>(CustomCertManager.kt:99) at at.bitfire.cert4android.CustomCertManager.<init>(CustomCertManager.kt:48) at at.bitfire.icsdroid.CustomCertificates.certManager(CustomCertificates.kt:20) at at.bitfire.icsdroid.SyncAdapter$ProcessEventsTask.processEvents(SyncAdapter.kt:153) at at.bitfire.icsdroid.SyncAdapter$ProcessEventsTask.run(SyncAdapter.kt:109) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607) at java.lang.Thread.run(Thread.java:761) [08-19 07:01:07.476 13158:13158 I/cert4android] CustomCertService destroyed [08-19 07:01:07.489 13158:13196 E/icsdroid] Thread interrupted java.lang.InterruptedException at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:2010) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2087) at java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1452) at at.bitfire.icsdroid.SyncAdapter.onPerformSync(SyncAdapter.kt:73) at android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:272)
Could this be related? Or could I look for anything else in the logcat? I have saved all logcat with the app “logcat reader” and saved them. So I can grep for anything which you might be interested in.
@meiser Ahh I think I know why it happens… when ICSdroid takes too long for parsing and evaluating the entries, the sync times out in Android and Android interrupts the thread. This causes various confusions, possibly including duplicate entries.
Is it true that it only happens for big feeds with many entries?
Is it true that it only happens for big feeds with many entries?
At least the feeds where I saw the issue had with many entries. If your diagnosis is true, it will not be reproducible with my above test URL.
@rfc2822 Yes, the feed has a lot of entries. Is there a way to delay the interrupt?
@meiser The thread is interrupted when there’s no I/O traffic. Solutions would be to make sure there’s always I/O traffic (has been done in DAVdroid 2.x, where the connection is only closed when there are no more entries to process; not applicable to ICSdroid) or to use something other than the sync framework.
If you or anyone else knows another solution, let me know…
Nice that we have found the source of the issue. I’ve since switched back to Google calendar and am putting up with the 24h delay between updates.
As a workaround, what about a proxy service that splits large ICS feeds into smaller chunks? Not sure if it’s realistic, or how ICSdroid would consume multiple chunks, just thinking out loud…
@chmac I wonder whether a sync adapter may start another service without the 1 min limit… this would be required so that “Sync now” in calendars still works.
@rfc2822 Sorry for my late reply. I had not tried re-adding all subscriptions (I actually wanted to avoid that). Anyways, I did it now and will report back if the error persists.
Thanks for the support!
Unfortunately, the issue also persists on my side.
It’s hacky, but would filtering out duplicates after aborted syncs be an option?
This bug makes using the calendar incredibly hard. I’ve had entries that are duplicated more than 20 times.
@rfc2822 Thanks a lot for your great support! I’ve just installed the new version and entered my subscriptions. I’ll report back in case I notice any problems.