Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sporadic high CPU-load when network connection is unstable #606

Open
tycho-kirchner opened this issue Jun 20, 2023 · 1 comment
Open

Sporadic high CPU-load when network connection is unstable #606

tycho-kirchner opened this issue Jun 20, 2023 · 1 comment
Labels
investigate Maintainer will try to reproduce this issue

Comments

@tycho-kirchner
Copy link

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

@kewisch kewisch added the investigate Maintainer will try to reproduce this issue label Jul 9, 2023
@scarlion1
Copy link

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. 😩

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
investigate Maintainer will try to reproduce this issue
Projects
None yet
Development

No branches or pull requests

3 participants