I created a local CalDAV server with Radicale and 2 later days KOrganizer started to throw error messages. Every time it tries to sync, KDE reports the following: "Items requested for an unknown collection". It seems KOrganizer is able to sync (I can see the new event on my mobile phone) but only with this error message. I have a WireShark capture, if it's needed I can upload it. KDE version: 4.9.2. Reproducible: Always
Same here, but with a davical calendar/addressbook store. I updated to 4.9.2 this evening, after the update I receive the notifications every 5 mins (i.e., per sync). I get two messages for the caldav (calendar) and the carddav (addressbook) store. I deleted and recreated the akonadi ressources, but this did not change anything. Server wasn't changed, my other devices (Android tablet and phone) can sync without any trouble. Syncing works, only the annoying notifications. .xsession-errors says "akonadi_davgroupware_resource_7(3020): Can't find a configured URL, collection.remoteId() is "akonadi_davgroupware_resource_7" The second source gives the same error but with "akonadi_davgroupware_resource_8".
Same problem here when syncing with Google calendar. It started with an update to KDE 4.9.2 this morning and since then the message pops up every few minutes.
Hi, Same problem here with ownCloud sync (caldav + carddav). Pretty annoying. KDE 4.9.2 Kubuntu 12.04.1
Same here. KDE 4.9.2 Kubuntu 12.04.1
Same here. Owncloud 4.0.7 KDE 4.9.2 Kubuntu 12.04.1
(In reply to comment #4) > KDE 4.9.2 > Kubuntu 12.04.1 Forgot: Owncloud 4.0.7
Created attachment 74360 [details] Non-fix, just a "silencer". Hi, here comes a non-fix, but a silencer. The problem is either * retrieveItems() is called with something which is not a collection or * some collections carry the bogus remoteId() "akonadi_davgroupware_resource_XX" which actually is just a local id.
I can confirm this happened after upgrading to KDE version: 4.9.2 on Kubuntu 12.04. It happens with both calendar and addressbook. Watchign the logs on my Davical server, I see that the error occur because the username is not supplied on the first request. Kontact then add the username and sync is done. However, it still keep sending the request without username, so the error message reappear. When configuring the account it makes no difference if I use global or local username. From my logs; 10.0.0.13 - - [07/Oct/2012:17:51:32 +0200] "PROPFIND /kalender/caldav.php/myUsername/adresser/ HTTP/1.1" 401 5947 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9" 10.0.0.13 - - [07/Oct/2012:17:51:32 +0200] "PROPFIND /kalender//caldav.php/ HTTP/1.1" 401 5947 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9" 10.0.0.13 - myUsername [07/Oct/2012:17:51:32 +0200] "PROPFIND /kalender/caldav.php/myUsername/adresser/ HTTP/1.1" 207 6267 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9" 10.0.0.13 - myUsername [07/Oct/2012:17:51:32 +0200] "PROPFIND /kalender//caldav.php/ HTTP/1.1" 207 6251 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9" 10.0.0.13 - - [07/Oct/2012:17:51:32 +0200] "PROPFIND /kalender/caldav.php/arne%40drlinux.no/ HTTP/1.1" 401 5947 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9" 10.0.0.13 - - [07/Oct/2012:17:51:32 +0200] "PROPFIND /kalender/caldav.php/arne%40drlinux.no/ HTTP/1.1" 401 5947 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9" 10.0.0.13 - myUsername [07/Oct/2012:17:51:33 +0200] "PROPFIND /kalender/caldav.php/arne%40drlinux.no/ HTTP/1.1" 207 6427 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9" 10.0.0.13 - myUsername [07/Oct/2012:17:51:33 +0200] "PROPFIND /kalender/caldav.php/arne%40drlinux.no/ HTTP/1.1" 207 6811 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9" 10.0.0.13 - - [07/Oct/2012:17:51:33 +0200] "PROPFIND /kalender/caldav.php/myUsername/adresser/ HTTP/1.1" 401 5947 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9" 10.0.0.13 - - [07/Oct/2012:17:51:33 +0200] "REPORT /kalender/caldav.php/myUsername/kalender/ HTTP/1.1" 401 5947 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9"
Well, that the first request does not contain a username is normal and expected. That's how auth works. You try, get rejected and supply pw/user. I can confirm that the error only occured after upgrade from KDE 4.9.1 to 4.9.2. More importantly I noticed that now all DAV collections in KOrganiser have a tickbox as if they were calendars themselves, which was nt the case in 4.9.1. It does not matter whether you switch them on or off, you cannot create items in them, since they are merely empty dummy collection folders. However I believe that Akonadi tries to sync them, which of course does not work. Fact is that I am not even getting any error anywhere in my server logs, which means that the DAV resource is not even trying to access any server for it. Ergo the error must be somewhere between Akonadi and DAV resource, or between the client (KAddressbook|KOrganizer) and Akonadi. Maybe Gregory has some ideas and can do some debugging but I suspect it's an error in Akonadi.
Same with me. Anyway to help debugging this? I don't have sources right know, but anything from that I'm willing to help.
Created attachment 74507 [details] Screenshot of the KMail autocompletion addressbook sources Have found another interesting hint: Addressbook autocompletion now has two more "Addressbooks": The top level DAV folders. This was no there before KDE 4.9.2.... Attached screenshot.
I just checked the KMail autocompletion settings and expected it to look just like Ingo's attachment - but it didn't. Then I noticed that I didn't hear or see anything of that error since a while. I checked and noticed I lost the connection to the server (I have a local ownCloud and resolve the hostname via avahi). Even the check mark next to the folder vanished. As soon as avahi redetected it an I triggered a manual update and voila - the check mark appeared again and the error was shown. Hope that helped.
Same annoying error pop-ups here every 5 minutes with KDE 4.9.2 and a normally working caldav server. Other clients can sync without error messages.
Reported on 10/2, annoying error messages all day long, many confirmations on several distros. Still "status: unconfirmed"? As for the "non-fix, just a silencer" - where can I find the file to apply the patch to? I tried "apt-get source akonadi-server", but couldn't find the mentioned files. Also "apt-get source libakonadi-calendar4" wasn't successful. In addition, I tried to get rid of the messages by disabling "application notifications" in the plasma notification widget. But this only made the messages appear in the center of the screen and no more in the notification widget. Sebastian
I think Ingo already nailed it where the error seem's to be located which matches which what Claus-Justus said and I noticed. retrieveItem() with something that is not an collection, which the containing folder is not. Sadly I don't know where to look in the code.
*** This bug has been confirmed by popular vote. ***
*** Bug 307779 has been marked as a duplicate of this bug. ***
Created attachment 74557 [details] Fix by revert Reverting 0ecdc1c34082224fff5f360b2d6c9a7bfe8c7ac3 fixes the problem for me. But I guess we need a better solution than just reverting it http://quickgit.kde.org/index.php?p=kdepim-runtime.git&a=commit&h=0ecdc1c34082224fff5f360b2d6c9a7bfe8c7ac3
No idea how Akonadi and co. work, however I think that I have to agree with the revert. It seems strange to have the parent collection (ie DAV folder) having all the mime types of all child collections. That would effectively tell Akonadi that the DAV parent folder has toDos and Calendar Entries as well as Address Books? Seems strange, since it's only a collection of collections not items.... so the one and only mimetype should be "directory" or whatever the mime type for it is. If that does not show up somewhere in KOrganiser, then KOrganiser needs to be fixed maybe by querying child-collections instead of root collections. Just my thought.
*** Bug 308509 has been marked as a duplicate of this bug. ***
Git commit 5e7db58608f39bceb94ff421abd48729cc46cf72 by Gregory Oestreicher. Committed on 17/10/2012 at 23:12. Pushed by goestreicher into branch 'master'. Don't call cancelTask() when an invalid collection is given The behavior introduced by 0ecdc1c34082224fff5f360b2d6c9a7bfe8c7ac3 caused a spurrious notification at each sync. Now just return an empty items list. M +2 -2 resources/dav/resource/davgroupwareresource.cpp http://commits.kde.org/kdepim-runtime/5e7db58608f39bceb94ff421abd48729cc46cf72
> Pushed by goestreicher into branch 'master' What about backporting into 4.9 branch? Bye Thorsten
Hi, > What about backporting into 4.9 branch? Done here: https://projects.kde.org/projects/kde/kdepim-runtime/repository/revisions/5e40280e8ec9e39d65b3b1a4e5ebecc4e62f8863 I haven't Cc'ed this bug report for the backport. Cheers, Grégory
*** Bug 309358 has been marked as a duplicate of this bug. ***
This is back in KDE 4.10.2 in Kubuntu 12.10. I upgraded last night and this (Google Calendar: Asked to retrieve items for an unknown collection:) pops up every 5 min. Should I try the revert mentioned above?
Could you try by re-creating the resource?
(In reply to comment #26) > Could you try by re-creating the resource? Thanks Grégory, that seems to have done the trick, although in a bit of a strange way. When I deleted the original calendar resource, I got an (actually several) error dialog saying it couldn't delete the folder or something to that effect, but the calendar was removed from the list. I created a new calendar but it didn't seem to be syncing with google so I exited Kontact and restarted. The original resource was back and the new one still refused to sync. The original error no longer occurs, so I deleted the newly created resource and have yet to see the 'unknown collection' error.