Regarding auto-discovery: have a look into our manual here for creating well-known paths or SRV/TXT records: https://www.davx5.com/manual/accounts_collections.html?#how-does-service-discovery-work It can make things really easy for users

@shellshocker if you can, open a support ticket with mailbox.org as I did just to push so that they solve the issue ASAP … Regards

Hi phy25, I have drop a debug file (attached in a previous comment). Here is a new one (I have attempted sme modifications but I actually do not get any error message when I synchronize) : https://fpaste.me/J17dzWTxhQ

@cogliano Thanks for the update!

This should hopefully be fixed with https://gitlab.com/bitfireAT/davx5-ose/commit/c9dab31067a186a6d4ca33cd742fedc8465ecf29.

Thanks for changing the title for me. As for the Qt-CalDAV thing - I totally understand that CalDAV doesn’t have anything to do with Qt or the way it interprets color values. Qt also doesn’t have any idea about CalDAV. If you asked me, then I would say that this is just a total coincidence that Korganizer correctly displays calendar colors sent by the Runbox calendar service. The support for SVG color names was implemented in QColor for totally different reasons, not with Apple’s calendar-color in mind (Qt as a programming framework just supports SVG as one of many graphics formats, that’s why QColor needs to understand SVG color names). QColor, of course, supports also RGB(A) color values. And most probably Runbox chose to use SVG color names for their calendars because it was just more convenient for them (we give users 120 predefined SVG colors for their calendars - they be happy; we have less work - we be happy as well). Unfortunately, I also have no knowledge of the Apple’s calendar-color specification. From the DAVx5 logs I just assumed that these color names are Apple-defined and are part of their calendar-color specification. Turned out that my assumption was wrong. It seems that this caused a lot of unnecessary confusion

Thanks. Works without problems here… which Android version do you have? May non-compatible TLS ciphers?

Thanks. If you find any hint in the standard that EXDATE should always have the same time zone as DTSTART (what if DTEND has a different one?), please let me now

I see. Probably this was something else than a space, which works without problems. The error message is strange, because I can’t remember that account names are validated with such messages. If an account can’t be added (because of the name), there is a generic error message. If this is of further interest, please provide exact steps to reproduce so that I can give it a try myself.

Ok, I solved the problem. It wasn’t related to DAVx5 but to MIUI. Looking in the synchronization options I realized that no account (google, …) had been synced for many days. And I manual sync did not work at all. I re-installed the latest MIUI version (via Options -> About the phone -> System-Update, In case anybody has the same problem) and now it works again.

Yes, that explains it for me. Thank you for your help.

Unfortunately no I added two more events (one in the past / one in the future) in my local Thunderbird/Lightning Calendar. They got synced to my caldav instance without a problem I manually started the sync progress on my phone with davx5 … but nothing changed on my phone Then I added a event in the past on my phone and started a manually sync with davx … and they got synced with my caldav instance without a problem (and even with Thunderbird/Lighning). But still, the other older events are not on my phone

Now when you mentioned it, i have indeed the app ‘force doze’ running and suspected it but i thought that icsx5 run smoothly for weeks. I will try to disable doze mode for icsx5. thank you.

@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.

@tartarian said in DavX thinks there is no internet even though there is: That is fine but it would be nice if the app does not rely on the system’s false flags if it is conenected or not. Maybe some kind of override would be nice for sure. DAVx⁵ is a sync adapter and relies on the synchronization framework of Android. If Android thinks there is not internet connection, it won’t call DAVx⁵ for synchronization. Please make sure that Android APIs work as documented on your phone; otherwise apps which use those APIs can’t work well. DAVx⁵ relies on working Android APIs, like many other apps. For instance, you won’t be able to receive emails or sync your Firefox data “without Internet connection” as well. I suggest to change the captive portal URL to something on your own server and de-block the connectivity check in your firewall. BTW, it’s called DAVx⁵ or DAVx5. Please don’t call it DavX.

Thank you for the information. Google is the only service we know that uses OAuth. It’d be a lot of work for only one service provider, so we didn’t do that yet. Please consider migrating away from their CalDAV/CardDAV services if you can’t/don’t want to use gapps…

Hello! Please have a look at our comprehensive manual on this matter: https://www.davx5.com/manual/accounts_collections.html?highlight=read only#read-only-collections If you have any other questions please feel free to ask

We appreciate you like it It was and still is a lot of work, and we will further improve it over the next years