sync problem with thunderbird and google calendar

[ERRVV1N]

I'm using TB 102.2.2 (64-bit) on Ubuntu 20.04.5 with gdata-provider 102.0.1 and the syncronization with Google Calendar hangs and TB is unusable.

[nneul]

I've been seeing this same problem, going into add-ons and choosing to disable the provider, (click past the unsubscribe dialog) and then immediately re-enabling provider seems to clear it up.

[kir0ul]

That fixed the issue for me 👍

[kir0ul]

But after some time the issue came back... 😓

[henry88g]

This didn't work for me, but restarting TB did. Fix is working after a while - will see how long it holds for.

[msjohns1]

I'm seeing a related problem. Synchronizing upstream changes does not function, from either the automatic sync or manually selecting to synchronize. It goes through the process, and does not cause TB to hang, but it also doesn't actually pull down any changes. If I fully close TB and reopen, that seems to trigger a successful sync. I haven't tried @nneul's suggestion, but I wonder if that would similarly trigger the sync. End result is the calendar state is unreliable.

TB 102.2.2 (64-bit) on Mint 20.3, Provider 102.0.0

[mackintg]

I have exact same versions as @msjohns1 and getting the exact same symptoms.

[msjohns1]

@mackintg I just tried @nneul's suggestion -- disable Provider, hit "Cancel" on the unsubscribe prompt, and immediately re-enable -- and then I was able to successfully create an entry directly in Google and a manual sync bring it into TB. So I recommend giving that a try; hopefully it resolves for you as well.

[mackintg]

@msjohns1 yes, I also tried @nneul's suggestion and it temporarily fixed the problem... but only for ~1 day and then it was back to no-sync of changes made on the gmail calendar outside of TB. I already downloaded the latest version 102.0.3 that is meant to resolve this problem (#519 (comment)) but no improvement is apparent.

My intuition is that a fix should be reasonably easy to resolve since most people can get TB calendars to sync by using @nneul's method or by just restarting TB. This means that there is a known state/config where TB syncs correctly and efficiently, so I hope that the developer is reviewing these comments and can create the same state whenever a calendar sync is required.

[xjonx1]

The app has to be updated. The developer has been contacted. The problem is the app needs google's new OAuth 2.0.

[ERRVV1N]

I was able to find out that it is due to Thunderbird and not the addon. The addon works very well in TB version 102.4.2 (64-bit/Ubuntu 20.04.5 with gdata-provider 102.0.1). I haven't been able to test all the features yet, but it seems to be working very well.

[msjohns1]

Thanks for the shout. I upgraded TB (but still using provider 102.0.0 since that's what the extension manager says is current) and my testing was successful. So hopefully this resolves things.

[xjonx1]

There was an issue with the add-on and is now fixed by the developer. Details here: #519 (comment)

[madtom1999]

Not working on 102.4.2 on 64 bit Xubuntu.

[nneul]

The updated plugin fixes the authentication issue, however I don't believe it fixes the sync problem in THIS issue - I saw a 'stopped syncing' instance yesterday AFTER I upgraded to 102.0.3. Will be keeping an eye on it to see if that problem reoccurs.

[xjonx1]

I had the plug-in self-remove itself from Thunderbird once but removing the old calendar and re-adding it seems to have fixed that problem. I merely mention that to say, did you remove(unsubscribe) from your calendar then add it back in? That may help, or it may not.

[mackintg]

Interesting that @msjohns1 found this problem was fixed by upgrading TB, because I am using TB 102.5.0 and the very latest gdata-provider 102.0.3 from github (here) , but I find that the calendar sync problem persists. So I am in the same situation as @nneul ... the gdata-provider update to 102.0.3 fixes the authentication problem, but not the sync problem that is the focus of this thread.

Various tricks, like i) disabling the add-on and adding it back, ii) unsubscribing from the calendar and then re-subscribing to rebuilding the calendar from scratch, iii) restarting TB ... these all seem to clear the problem for a while. But my experience is that the no-sync problem eventually returns when an existing calendar entry is modified outside of TB, and that modification will not sync into TB until I do one of the things mentioned above.

As I posted earlier, my hope is that a fix should be forthcoming since most people can get TB calendars to sync by using @nneul's method or by just restarting TB. This means that there is a known state/config where gdata-provider will sync correctly and efficiently, so I hope that the developer is reviewing these comments and can create that same state whenever a calendar sync is required.

[dellskin]

I am on TB 102.5.1 64-bit and Provider 102.0.3. I think this was working(maybe, can't remember) in TB 102.5.0, but not working now (my TB updated yesterday). Turning off and on the Provider does not work, it only loads and fixes data as of that moment. It does not fix the problem on an ongoing basis.

[MaxMotovilov]

102.5.1/64 + 102.0.3. Calendars sync when TB starts up and, I think, never again.

[mackintg]

I don't think this is going to be fixed any time soon. The work-around that I have settled on takes advantage of the fact that restarting TB fixes the calendar sync problem for a period of time (but unfortunately the exact circumstances that lead to the calendar sync failing again are still unknown). I created a system-idle trigger to run a script when I am not using my computer, which restarts TB if it is active (e.g. using cron in Linux, or Task Manager in Windows). Restarting TB every couple of hours (if idle for, say, 30 minutes) seems to keep the problem under control for me while I wait for a real fix!

[kboeckx]

Same issue here, sync it only performed when starting TB or disabling/enabling the add-on. Please fix as this issue is there since a few mounths.

[Numiah]

As others I am still struggling with this issue.
Using TB 102.7.2 and GC 102.0.3
Solution for me is disabling the extension and using the google.calendar through a webbrowser.

[carlosabalde]

Anything we could do to help troubleshooting this? I'm not familiar with TB plugin development, but providing some basic guidance on the data to be collected that could be useful to diagnose whatever is going on here, I'd be very happy to help.

[carlosabalde]

I've been trying to do some troubleshooting on my own (zero knowledge on TB plugin development). I used the TB Config Editor to enable calendar.debug.log and calendar.debug.log.verbose (not sure if that changes anything, but it's documented in the repo), and then I used the Error Console (Ctrl + Shift + J).

Every time I clicked 'Calendars > Synchronize', I saw some reasonable logging in the console:

10:17:22.771
GEThttps://www.googleapis.com/calendar/v3/calendars/addressbook#[email protected]/events?maxResults=1000&showDeleted=true&syncToken=EDITED
[HTTP/2 200 OK 294ms]

10:17:22.772
GEThttps://www.googleapis.com/calendar/v3/calendars/[email protected]/events?maxResults=1000&showDeleted=true&syncToken=EDITED
[HTTP/2 200 OK 158ms]

10:17:22.773
GEThttps://www.googleapis.com/calendar/v3/calendars/EDITED/events?maxResults=1000&showDeleted=true&syncToken=EDITED
[HTTP/2 200 OK 141ms]

10:17:22.838
GEThttps://www.googleapis.com/calendar/v3/calendars/[email protected]/events?maxResults=1000&showDeleted=true&syncToken=EDITED
[HTTP/2 200 OK 150ms]

10:17:22.839
GEThttps://www.googleapis.com/calendar/v3/calendars/[email protected]/events?maxResults=1000&showDeleted=true&syncToken=EDITED
[HTTP/2 200 OK 166ms]

10:17:22.840
GEThttps://www.googleapis.com/tasks/v1/lists/EDITED/tasks?maxResults=1000&showCompleted=true&showHidden=true&updatedMin=2023-03-01T09:16:10Z&showDeleted=true

Sometimes I clicked the button and nothing was logged, but I assume some logic exists to ignore updates if they are requested too frequently. However, at some point (yesterday it took several hours), clicking the button stops logging anything at all. I've been looking for previous log messages, but nothing seems related with this issue. Of course, as commented several times here, disabling-enabling the add-on restores the normal behavior.

I'd love to help here, but I'd need some guidance in order to know what I should adjust to get additional logging and hopefully get some clues :)

[carlosabalde]

OMG, such a delightful, helpful, friendly & collaborative attitude! I'd love to return the favor and suggest you click the unsubscribe button, but instead I'll keep waiting for your contribution to the problem. Have a nice day you too! ;)

[carlosabalde]

Based on my previous observations, I've cloned the repo, made a minor adjustment to the implementation, rebuilt and installed the modified add-on. So far the sync issue seems to have been fixed, although I'd like to let this run for a few days before jumping to any conclusions.

In any case, for the sake of those who may be interested, the modification is as simple as skipping the logic to bypass sync when the user is idle. Anybody here with a deeper understanding than me of the add-on's internals who knows the negative implications of this modification / can suggest a less hacky solution? @kewisch I'm looking at you :) It'd also be great if others experiencing the same issue could confirm if this fixes the problem for them too.

[carlosabalde]

Here it is the built add-on including the described fix, for those who want to give it a try: gdata-provider.xpi.gz. For me, so far, no more sync issues.

[nneul]

What commit/branch/tag did you base your changes on? Maybe I'm just out of date/sync. I'll take a look at your build. (I was against oauth2, trying now against legacy).

[carlosabalde]

Tag v102.0.3, which is the latest release.

[nneul]

Looking at that chunk of code, I think the issue is that it's tripping on the "idle" - and then never re-enabling the handler here:

gdata-provider/src/legacy/modules/gdataCalendar.jsm

Line 901 in 375ad8c

this.replayChangesOn(aListener);

          this.replayChangesOn(aListener);

A more "correct" fix might be just to skip all the "processing" pieces in that function, and jump straight to that last function that resets the callback.

[carlosabalde]

Makes sense, but my JavaScript knowledge is basically nonexistent :) In any case, as long as we can confirm the problem is in there, writing the right fix should be simple. Did the ugly hack suggested by me fix the problem for you too?

[nneul]

Giving the fix a try now and will let you know.

[nneul]

This may be something with what I built - but I'm getting the google login every 30 minutes now - doesn't appear to be "sticking".

[carlosabalde]

I've using the modified add-on since yesterday and that didn't happen. You can give a try to the once I attached in the previous thread.

[nneul]

Since rebuilding against 'legacy' branch instead of oauth I haven't seen any issues with the workaround and it seems stable.

[jachoo]

I've managed to workaround the bug without rebuilding or reinstalling. Just run in the console (Tools -> Developer Tools -> Debug Addons -> Provide for Google Calendar -> Console) following line:

await messenger.storage.local.set({"settings.idleTime": 0})

After executing this line, one must restart Thunderbird. From now, the calendar sync should work correctly.

[matt-buckley]

Worked for me as well with the more recent issues being reported!

[atscomms]

Worked for me, so far!
Thanks!

[otaolafranc]

Hello,
I just found myself with the same issue, and I can not find 'Tools -> Developer Tools -> Debug Addons -> Provide for Google Calendar -> Console'
version 115.9.0 (64-bit)
any ideas/recommendations?

[paeddi]

With the new UI you should find the console under Addons, than the gear symbol (manage extensions), debug Add-Ons, and then inspect (I hope it is called like that in english UI...) for the Provider for Google Calendar.
but I'm not sure if that's still the solution... ;-)

[otaolafranc]

Hello @paeddi thanks for your answer, I managed to do it (I think), but the problem reminds for me sadly

[kewisch]

Anyone who is working around this issue with the settings.idleTime hack, I need help to debug/fix this in #498 .