Syncing stopped working

[dmolineus]

I use to synce ICS files from two different sources. One source from outlook.offfice365.com stopped working, reproducable on two different devices (Last sync was on 19. August, maybe related with update to version 2.3.1). The ics file generated by outlook.office365.com is accessible on the browser and other clients though.

Bug still exists on latest version 2.4.0

HTTP 500 

java.io.IOException: HTTP 500 
	at at.bitfire.icsdroid.CalendarFetcher.fetchNetwork$icsx5_88_2_3_1_gplayRelease(SourceFile:180)
	at at.bitfire.icsdroid.CalendarFetcher$fetchNetwork$1.invokeSuspend(Unknown Source:11)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(SourceFile:33)
	at kotlinx.coroutines.DispatchedTask.run(SourceFile:100)
	at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(SourceFile:124)
	at kotlinx.coroutines.scheduling.TaskImpl.run(SourceFile:89)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(SourceFile:586)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(SourceFile:820)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(SourceFile:717)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(SourceFile:704)

[sunkup]

We did not change the standard user agent of ICSx5, but now you can override it when adding or editing a subscription.

Please edit your office365 calendar subscriptions and add one of the suggested user agent strings, or provide your own in the text box.

[joendres]

Thank you very much!

[dmolineus]

Thanks, that work's for me.

[whippgwork]

Hi. Since version 2.4.0 pushed out to my Pixel 9 Pro I am seeing sync errors.
Specifically I see 'expected 0 bytes but received 20' when I sync my calendars from dropbox.
This has always worked perfectly in the past and I have changed nothing from my side.
If I click on the error this is the full error text I see

`expected 0 bytes but received 20

io.ktor.utils.io.ClosedByteChannelException: expected 0 bytes but received 20
at io.ktor.utils.io.CloseToken$wrapCause$1.invoke(SourceFile:16)
at io.ktor.utils.io.CloseToken$wrapCause$1.invoke(SourceFile:16)
at io.ktor.utils.io.CloseToken.wrapCause(SourceFile:21)
at io.ktor.utils.io.CloseToken.wrapCause$default(SourceFile:16)
at io.ktor.utils.io.ByteChannel.cancel(SourceFile:141)
at io.ktor.utils.io.ByteWriteChannelOperationsKt$writer$job$1.invokeSuspend(SourceFile:187)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(SourceFile:33)
at kotlinx.coroutines.DispatchedTask.run(SourceFile:100)
at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(SourceFile:124)
at kotlinx.coroutines.scheduling.TaskImpl.run(SourceFile:89)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(SourceFile:586)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(SourceFile:820)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(SourceFile:717)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(SourceFile:704)
Caused by: java.net.ProtocolException: expected 0 bytes but received 20
at okhttp3.internal.connection.Exchange$ResponseBodySource.read(SourceFile:327)
at okio.RealBufferedSource.read(SourceFile:85)
at io.ktor.client.engine.okhttp.OkHttpEngineKt$toChannel$1.invokeSuspend$lambda$2$lambda$1(SourceFile:172)
at io.ktor.client.engine.okhttp.OkHttpEngineKt$toChannel$1.$r8$lambda$RFpk0Qfk8hGIVZyOFOdDpP9vSkk(SourceFile:0)
at io.ktor.client.engine.okhttp.OkHttpEngineKt$toChannel$1$$ExternalSyntheticLambda0.invoke(SourceFile:0)
at io.ktor.utils.io.ByteWriteChannelOperations_jvmKt.write(SourceFile:28)
at io.ktor.utils.io.ByteWriteChannelOperations_jvmKt.write$default(SourceFile:24)
at io.ktor.client.engine.okhttp.OkHttpEngineKt$toChannel$1.invokeSuspend(SourceFile:170)
at io.ktor.client.engine.okhttp.OkHttpEngineKt$toChannel$1.invoke(SourceFile:0)
at io.ktor.client.engine.okhttp.OkHttpEngineKt$toChannel$1.invoke(SourceFile:0)
at io.ktor.utils.io.ByteWriteChannelOperationsKt$writer$job$1.invokeSuspend(SourceFile:179)
... 8 more`

[whippgwork]

Hi. Thanks for the quick reply
Please find attached a text file of the Calendar from my Dropbox (I cant share the exact link due to it being my personal dropbox)
You'll need to rename it to 'F1.ics'
You can then host it on a dropbox account and subscribe to it using the dropbox link for the file
The dropbox link will look like 'https://www.dropbox.com/scl/fi/randomstring/F1.ics?rlkey=randomstring&dl=0'
Just substitute dl=0 with dl=1 and paste the link into ICSX5

F1.txt

[sunkup]

@whippgwork

I tried doing as you said - renaming and sharing via my own dropbox, but I don't get the error you show. It works just fine for me and the calendar subscription gets added without issues.

Since this error comes from OkHttp (http client used in ICSx5) and indicates a mismatch between what the HTTP protocol expects and what the server actually sent, I think this is a server-side bug or misconfiguration, which might have been fixed already?

Please try deleting the existing ics file, re-uploading it and then sharing it and subscribing again. Does that fix it?

[whippgwork]

@sunkup

Hi
Thanks very much for looking at this

I have:

• deleted the orignal F1.ics subscription from the ICSX5 android app on my phone
• closed the app and emptied app cache
• pasted the contents of the ICS file to a new text file on my windows desktop and saved as F1.ics
• deleted the old F1.ics file from my dropbox folder
• copied the new F1.ics file into my dropbox folder from my windows desktop and let it sync up
• got the dropbox link for the new file
• subscribed to the new file in the ICSX5 app

It subscribed fine but then says under the entry 'not syncronized yet'
As soon as I pull down to refresh it shows 'expected 0 bytes but received 20' in red
The only way I can clear the error is to manually go into the 3 dot menu in the app and select 'Force Sync'
At this point the date and timestamp are updated and the red error goes away

[sunkup]

I see. I did not do the refresh, but when I do it happens for me too. Since it's a serverside misbehaviour I think we could simply choose to ignore it in ICSx5, but will check. Tracked in #700

[whippgwork]

Thanks for your efforts. Glad you could see the issue too and have a fix planned