Hm, I guess the problem is the unescaped ; in the X-APPLE-STRUCTURED-LOCATION line. I don’t think there is an easy way to work around that. Creating a new calendar without that event like suggested by @devvv4ever is probably the best solution.
The issue with published Office365 Calendars is they do not include VALARM attributes - so, of course you won’t be able to sync reminders with ICSx⁵.
Here is an example of a published calendar, that (in Outlook,) has a 15 min reminder, which does not show up in the ICS document.
You can add reminders manually to the Android calendar (after the subscription pulls down events) - but the next sync overwrites these events, wiping out any reminders you may have set.
As a work around, would it be possible to add an option to not remove reminders that have been set manually (if the ics data does not contain VALARM attributes?)
@lajuga said in Unable to setup a subscription because of timeouts:
Isn’t it more that if the request is fulfilled after 5 seconds the user has had a wonderful experience of reactivity and everything is fine and a set timeout never came into play?
No, reactivity doesn’t mean that the desired result is achieved at all, but that it’s achieved in acceptable time. It is not acceptable to wait 1 or 2 minutes for a simple calendar to be refreshed, because this time is far too long for what is possible and indicates severe implementation problems.
Actually I very much would prefer the calendar data to be delivered at all, even if that would mean that I had to wait two minutes for it. Patience is a virtue and seriously: so what if it takes five minutes to update the calendar data?
Basically, there’s nothing wrong with that. Let me describe the situation: What whould you think about ICSx⁵ if it took 5 min to start (from the time you click on the launcher icon)? I could say, well it does important things, it calculates the calendar list and renders some colored dots, it takes 5 minutes. Wouldn’t you say that’s unacceptable and choose another app which launches immediately?
You are certainly right, that the server side seems to suck big time, but often - as e. g. in my case - there is simply no way to change anything there.
Which leads to an important question: Why does your server take that long? What do server admins/support say about that?
I can reproduce the problem. The (a) problematic event is
This is an event without end (no COUNT or UNTIL in RRULE), and it seems that the existence of RDATE/EXDATE in such events can’t be processed by the Android calendar provider, which sends:
icsx5 : Found VEVENT: firstname.lastname@example.org
icsx5 : email@example.com not in local calendar, adding
RecurrenceProcessor: DateException with r=FREQ=MONTHLY;WKST=MO;BYDAY=3SU rangeStart=135390560256 rangeEnd=9223372036854775807
CalendarProvider2: Could not calculate last date.
CalendarProvider2: com.android.calendarcommon2.DateException: No range end provided for a recurrence that has no UNTIL or COUNT.
CalendarProvider2: at com.android.calendarcommon2.RecurrenceProcessor.expand(RecurrenceProcessor.java:768)
CalendarProvider2: at com.android.calendarcommon2.RecurrenceProcessor.expand(RecurrenceProcessor.java:663)
So, it seems that such events are not supported by Android.
Why not use 15 min in this case? Files are only downloaded when they have changed, so 15 or 30 min shouldn’t make much difference.
This is precisely what I’m currently doing, Not that I wouldn’t preferred the proposed alternative, Including having different intervals, but I see the opposite is documented.
With this new update, I am seeing an issue where new subscribed events while syncing do not show up at the right time. They show up the night before as a short event. This was an issue with a version about a year ago and it seems to have returned in this version.
ICSdroid is lacking a setting that prevents to sync without wifi. It’d be pretty useful, not just to prevent using mobil data transmission, but also to prevent sync failures, which are possible when not having good mobile connection. Notice DAVdroid does offer the setting.
Thank a lot !