You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I ended up here as a follow-up on this bug-report which I recommend to read, as it explains, how we found out, that this appears to be indeed a google-calendar bug. In brief:
The google-calendar periodically performs it's synchronization, which is visible for the user in form of the top spinning wheel.
However, when the network connection is unstable, sporadically, this sync action never completes. As the spinning wheel animation, for whatever reason, is quite cpu-intensive, the resulting battery drain is a major problem for me when doing a journey.
In this bug-report I also described steps to reproduce in TB v102.11.0:
setup a google calendar account in TB
switch to the calendar tab and make sure, that all notifications are dismissed
configure your network so that it points to an invalid gateway and DNS address. For instance, my normal router address is
192.168.178.1, I changed gateway and DNS both to 192.168.178.189
rightclick on your google cal and hit "Synchronize Calendars"
switch to main (inbox) tab and see the wheel spinning. Eventually it is necessary to hit "Synchronize Calendars" multiple times, but I
never had to do it more than four times.
verify that the spinning wheel never stops. Eventually, on re-establishing the internet connection "fast enough", the spinning stops,
but in my experiments, after spinning for longer than 10 minutes, it never stopped again until closing TB.
Further, after having enabled calendar.debug.log, the console contained the following line:
Calendar: [calGoogleCalendar] Error syncing:
2152398878:[Exception... "The lookup of the hostname failed" nsresult: "0x804b001e (NS_ERROR_UNKNOWN_HOST)" location: "JS frame :: resource://gdata-provider/legacy/modules/gdataRequest.jsm :: fail :: line 239" data: no]
So, while I'm not definitely sure whom to blame, it seems likely that this plugin plays a role and I would kindly ask to investigate this issue which has been around for years.
Thanks
Tycho
The text was updated successfully, but these errors were encountered:
I have this issue all the time. I think maybe it's related to having to connect and re-connect to my work VPN every 24 hours? Although I wouldn't exactly call it an unstable connection, because there is nothing in TB or within my Calendars that requires the VPN to access. However, once connected to the VPN and routing table updated, there are surely some connections that may get routed through the VPN, including a work calendar.
Although, since this is a Google calendar provider, connections are to Google and not my work thus never involved the VPN. Still, it's likely related and I will see the spinning wheel--actually it's a bouncing line on Linux, still CPU intensive since it shares the graphics. Only fix is to close TB.
I would love to know how to turn on calendar debug log, maybe further info there can help. Also if you know of a way to workaround it and just terminate the connection, perhaps a console command? That would be awesome because I really hate having to close TB since I use it for 3 business and have like 10 accounts in there plus 10 calendars and it's just annoying to retype master password and re-lay 3 windows with the desired folder views, etc. 😩
Hi,
I ended up here as a follow-up on this bug-report which I recommend to read, as it explains, how we found out, that this appears to be indeed a google-calendar bug. In brief:
The google-calendar periodically performs it's synchronization, which is visible for the user in form of the top spinning wheel.
However, when the network connection is unstable, sporadically, this sync action never completes. As the spinning wheel animation, for whatever reason, is quite cpu-intensive, the resulting battery drain is a major problem for me when doing a journey.
In this bug-report I also described steps to reproduce in TB v102.11.0:
192.168.178.1, I changed gateway and DNS both to 192.168.178.189
never had to do it more than four times.
but in my experiments, after spinning for longer than 10 minutes, it never stopped again until closing TB.
Further, after having enabled
calendar.debug.log
, the console contained the following line:So, while I'm not definitely sure whom to blame, it seems likely that this plugin plays a role and I would kindly ask to investigate this issue which has been around for years.
Thanks
Tycho
The text was updated successfully, but these errors were encountered: