update: The export from WoltLab is wrong; the last Event in the ical file is 16. May.
I guess this is caused by the “Sub-Categories” in Woltlab. I had to export each sub-category by its own to get it working. Thank you for your help, this issue is solved.
Sadly, there is no error by manual sync. Is there any logfile written by the app I may provide?
Already tried to wipe data and reinstalled from F-Droid store.
Here are some random images that may give you more information.
Seriously, I have no clue what is wrong:
3_1523612498932_Screenshot_20180413-102615_01.jpg 2_1523612498932_Screenshot_20180413-102702.jpg 1_1523612498932_Screenshot_20180413-102722.jpg 0_1523612498932_Screenshot_20180413-112150.jpg
acknowledged = "ACKNOWLEDGED" acknowledgedparam ":" datetime CRLF
acknowledgedparam = *(
; the following is OPTIONAL,
; and MAY occur more than once
In your iCalendar resource, there are two colons (:), which is not parseable.
So, this is an invalid iCalendar file. Please fix the your iCalendar or report this problem (including this analysis) to someone who can fix it.
I understand your problem but don’t you just want to whitelist ICSdroid? The battery isn’t affected much by making an exception for ICSdroid. It’s just the that it gets the possibility to sync automatically on shorter intervals - you can still set once per day.
One other issue (quick feedback): When creating a new ics calendar, when enters the URL and the absolute path of the URL becomes the cal’s name, for posteo this is something like /calendars/ics/dasd882342332234234 as cal name. Would be better if one could enter Name and URL when adding a new ics.
Hi! It doesn’t make much sense to also copy LOCATION and DESCRIPTION, I think. Copying the SUMMARY has a practical outcome for the user because of the display in the calendar not being “—” anymore. Isn’t it enough to solve the problem just by copying the SUMMARY field?
Sounds reasonable to me to look e.g. for a “BEGIN: VCALENDAR” and a “BEGIN: EVENT” as well as for a closing “END:VEVENT” and “END:VCALENDAR” as a basic validation. I think from a user perspective this should be fine, the subscription would be fast and as it can happen at any time that a once valid resource becomes invalid (maybe due to an error while the .ics file was created, or a failed file download, or…) I don’t see a drawback in validating the whole file only when synchronizing.
@rfc2822 Thanks for the explanation, makes sense! If ICSDroid can’t omit downloading the whole .ics file, wouldn’t a “time limit” at least lighten the burden for creating entries in the Android calendar (and in consequence speed up any application displaying this smaller calendar)?