As I understand it, it’s an eM Client problem, because it treats LABEL as a separate address. Please follow up here: https://forum.emclient.com/t/contacts-wont-display-address-in-column-when-vcard-uses-lower-case-type/45285/7

So, the Nokia support replies and said that this is an App issue of DAVx5 but I have to wait for future Updates of the Phone too The support isn´t good and the 7.2 is a buggy phone with a lot of problems. All updates and patches bringing new problems. I decided to send it back and buy another phone. I hope this will help.

I have added it to “Known problems” here, too: https://www.davx5.com/tested-with/icloud

Until this is fixed in the server, we have added a workaround which is shipped with DAVx5 3.1-rc1 (latest beta on Google Play). Does it work for you with 3.1-rc1 again?

Sorry I didn’t have time to try it during the weekend but I tested it now and it seems to be working. Thank you for the quick fix!

Hi @rfc2822 thanks for the swift response - this is what I feared. Anyway, your very helpful FAQ page pointed me to a very nice alternative app (Etar) so I can even ditch Google Calendar completely - huray! Keep up the great work you are doing on DavX5, I am a very happy long-time user. All the best, Simon

@rfc2822 Thanks for taking a look. 20191121T035347Z is exactly 90 days prior to when the request was made. Davx5 is configured to begin searching for events 90 days prior. I assumed CAL:time-range start=“20191121T035347Z indicated the start point for that range. Is that not the case? Nevermind, I misread your reply. I’ll look for broken events in that range and see what I can find. Thanks for your help.

Hello, After DAVx⁵ has uploaded a task, the server replied with 204 No Content, which means that the task has been created correctly and there’s no further information about that. A 204 response is terminated by the first empty line after the header fields because it cannot contain a message body. In your case, the server has sent additional information (20 bytes) together with the status “there is no further information”, so this doesn’t make sense and can’t be processed. It’s probably some misconfiguration of the server or the (reverse) proxy; please contact your admin for more information.

@cogliano Thanks for the update!

@schiri thank you for digging into this and reporting the outcome here. very appreciated! Glad that there is no issue on our side Recurring tasks and sub-tasks are supported in acalendar+ tasks and can be synced via DAVx5.

@martin-grotzke said in UID of imported invitation/event overwritten: Then the issue is only, that for the first sync the ics that DAVx sends to SOGo does not contain METHOD:REPLY (and in consequence on organizer side the attendee status is not updated). But this METHOD:REPLY is set when I accept/decline the invitation after the initial sync was done. Would it make sense to set METHOD:REPLY for the initial sync already if the organizer is not the attendee for that the invitation was accepted/declined? DAVx⁵ never sets METHOD, because this is CalDAV Scheduling, which is not supported by DAVx⁵. The Android calendar provider doesn’t have the possibility to store the required fields for that. But this METHOD:REPLY is set when I accept/decline the invitation after the initial sync was done. I don’t understand that. Do you think DAVx⁵ sets METHOD:REPLY? It’s only possible that it keeps it as an “unknown property” when it has received it from the server.

Thanks for the whole file, I’ll have a look.

Yes this helped, thank you

I emailed this to support, and they referred it to their 3rd line support. I guess they will fix it - or not. There is not much I can do now but wait and see if it starts working at some point. I guess this is not a common problem, otherwise some user-agent spoofing option could fix this more generally(?)

@otiel Thanks for the update!

OK, so i can ask the kolab people if they have any idea about the problem. But like i wrote bevor, it was working with this config for a couple of month without any problems. also my network settings didn´t changed in the last month… And i have no idea where i can check this on the kolab site… But i hope i will get this fixed.

@acu Works here again, too. I’ll set this to solved.

@bingo Thanks for the update!

@Dan-cer Thanks for the update! Good that it now works for you

@executive Of course this would be desirable. I have created a feature request for that: https://github.com/ical4j/ical4j/issues/350