Sometimes some (but not all) of my configured calendars are not displayed and recognized anymore by akonadi. After a restart of akonadi the calendar is back, but all are settings lost (e.g. color settings, reminder settings). I have observed this bug on several machines with the same calendar, which resides on a davical server (version 1.1.1) The bug seem to happen most of the times directly after starting the machine. Often, but not always the bug goes along with a warning box "Error while trying to delete calendar item. Error was. Not items found". (see screenshot) This bug started to occur in 4.14.0 and is still present in 4.14.3. Reproducible: Sometimes akonadi status gave me this result in the broken state: $ akonadictl status Akonadi Control: running Akonadi Server: running search paths: ("/usr/lib64/kde4/plugins", "/home/till/.kde4/lib64/kde4/plugins/", "/usr/lib64/kde4/plugins/", "/usr/lib64/qt4/plugins", "/usr/bin", "/home/till/.kde4/lib64/kde4/", "/usr/lib64/kde4/") Akonadi Server Search Support: available (Remote Search, Akonadi Baloo Search Plugin) Available Agent Types: akonadi_akonotes_resource, akonadi_archivemail_agent, akonadi_baloo_indexer, akonadi_birthdays_resource, akonadi_contacts_resource, akonadi_davgroupware_resource, akonadi_folderarchive_agent, akonadi_followupreminder_agent, akonadi_ical_resource, akonadi_icaldir_resource, akonadi_imap_resource, akonadi_invitations_agent, akonadi_kabc_resource, akonadi_kalarm_dir_resource, akonadi_kalarm_resource, akonadi_kcal_resource, akonadi_kdeaccounts_resource, akonadi_knut_resource, akonadi_localbookmarks_resource, akonadi_maildir_resource, akonadi_maildispatcher_agent, akonadi_mailfilter_agent, akonadi_mailtransport_dummy_resource, akonadi_mbox_resource, akonadi_migration_agent, akonadi_mixedmaildir_resource, akonadi_nepomuk_feeder, akonadi_newmailnotifier_agent, akonadi_nntp_resource, akonadi_notes_resource, akonadi_openxchange_resource, akonadi_pop3_resource, akonadi_sendlater_agent, akonadi_vcard_resource, akonadi_vcarddir_resource
Created attachment 90034 [details] displayed warning
This bug is still valid for 4.14.6 and akonadiserver 1.13.0. Furthermore, the deletion message seems to be fixed, but the problem described here still exist.
One further thing i have noticed: The resource, which goes down is the only writable resource.
I experience the same behavior on kde 4.14.2 kaonadi 1.13.0 (Debian Jessie) with owncloud 8 as the server. It happens after resuming from suspend. In order to exclude the problem being caused by the fact that my $home and the configs in there have been growing for years, I created a new user. Same thing there.
Reconfiguring my network got rid of the issue! I had the same thing on debian for over a year, my Owncloud calendar and address book (both of them DAV groupware ressources) disappeared after reboot or resume from suspend. Some time ago, I was playing around with hostapd, and from that time, I had my network card manually configured as a bridge. Yesterday, I removed the bridge and made network-manager to take care of the connection: now it works. Stupid networkmanager...
I have dug a bit deeper into the code and have a question to all people observing this bug: Can you see the error message "Unable to fetch collections" in your ~/.xsession-errors ? Is the occurrence of such string in relation to the described bug?
Git commit b3bfa11aae9b6d7696bae7de0bf5afdc79a91fba by Grégory Oestreicher. Committed on 25/06/2015 at 20:42. Pushed by goestreicher into branch 'KDE/4.14'. Pre-validation of the collections propfind response Not sure if this may explain the disappearing collections in some cases but here goes. Extra validation can't hurt. M +19 -1 resources/dav/common/davcollectionsfetchjob.cpp M +1 -0 resources/dav/common/davcollectionsfetchjob.h http://commits.kde.org/kdepim-runtime/b3bfa11aae9b6d7696bae7de0bf5afdc79a91fba
THX for the fix. I would like to test it, but i am currently stuck here with my setup. I would like to install the updated akonadi resource side by side with my regular one. Maybe you can help me out: - I have already checked out the 4.14 branch an compiled it. I now have a install folder which contains kdepim-runtime including the akonadi resource. - Now i have copied the davgroupwareresource.desktop file and modified the following lines: Exec=/home/till/data/programmierung/kde/inst/4.14/bin/akonadi_davgroupware_resource X-Akonadi-Identifier=akonadi_davgroupware_testing_resource Name=DAV groupware resource (TESTING) My wish was that i now can add an extra testing resource in akonadi, But i dont see it. Any suggestions?
(In reply to Till Schäfer from comment #8) > - Now i have copied the davgroupwareresource.desktop file and modified the > following lines: under /usr/share/akonadi/agents/
my issue is resolved misspelled the exec path. i will give a feedback as soon i can see there is a difference. (it usually taskes some time before the error occurs)
i am sorry, but the bug occurred again using the current git version.
OK, do you happen to remember what you did when this occurred again? Anything that would help me reproduce it, because as it stands I'm completely clueless as to how this may happen.
This time the bug occurred directly after a reboot. That means: after i typed in my password for kwallet, I opened Kontact and the calendar was not there. I have not found a reliable way to trigger it, but it occurs regularly (every 2 or 3 days). I have also noticed this bug after standby/hibernate and once after i left Kontact running for a ling time without a reboot (2 or 3 weeks). The standby/hibernate problem seems to be fixed, since i am using network manager (see above). The reboot problem is the most frequent one. One further thing, that might help. This bug occurred the first time to me in the KDE release directly after the Bug 335090 was hot fixed (Git commit c9a781f5b61813da80a31793bb6ce90b6f2e9046; the broken state fix, not the second fix with missing conflict resolution). Maybe there is some connection here. I am willing to further assist you to find the bug. You can provide me with a version that logs every step or something like that. If the bug occurs i will send you the log files and the exact time of occurrence.
a few further informations: -> I have a single resource with several calendars, but only a single calendar vanishes and loses the settings. The problematic calendar is the only writeable calendar of the resource. -> I had two resources configured, pointing at the same calendar, during the test of your patch. The bug occurred simultaneously for both resources. Therefore, there seems to be a resource independent trigger for the bug. - The davical server lives on my home internet connection with a 24 hour IP address renewal. As I have seen the bug today again (on my work computer, which is outside my home network) after letting the resource run for a longer time (>24h), I was asking myself if there is a relation between a temporarily unavailable server and the occurrence of this bug.
Git commit 3122234bb6a3f3690a8f4f90dae5931d27423756 by Grégory Oestreicher. Committed on 10/08/2015 at 21:01. Pushed by goestreicher into branch 'Applications/15.08'. Forward the principal fetch job response code This may explain the disappearing collections problem if the principal fetch job times out but the subsequent collections discovery jobs don't and return an empty set. M +14 -7 resources/dav/common/davcollectionsfetchjob.cpp M +2 -1 resources/dav/common/davprincipalhomesetsfetchjob.cpp M +2 -1 resources/dav/common/davprincipalhomesetsfetchjob.h http://commits.kde.org/kdepim-runtime/3122234bb6a3f3690a8f4f90dae5931d27423756
Git commit 87dfde58b2169b1f083c6f2e7d314af03477e46a by Grégory Oestreicher. Committed on 29/08/2015 at 22:13. Pushed by goestreicher into branch 'Applications/15.08'. Also forward errors when the principal fetch job fails M +2 -0 resources/dav/common/davcollectionsfetchjob.cpp http://commits.kde.org/kdepim-runtime/87dfde58b2169b1f083c6f2e7d314af03477e46a
IIRC this was fixed following a private exchange with Till, but feel free to reopen if I misremember.