Bug #331

Client disconnects from core if downloading scrollback takes over 60 seconds (i.e. on a slow connection)

Added by TerrorBite about 15 years ago. Updated almost 15 years ago.

General / Unspecified
Target version:
Start date:
Due date:
% Done:


Estimated time:


When using Quassel on a slow connection, it takes more than 60 seconds to download all the scrollback from the core. In that time, the client detects that no heartbeat has been sent from the core for 60 seconds, and closes the connection.

SUGGESTED SOLUTION: Disable heartbeat checking while scrollback is being downloaded.


#1 Updated by hagabaka about 15 years ago

I have this problem even when I run the core and client on the same machine. I have 7 networks and about 40 channels open so it takes a while for the client to download messages on start up. The client often displays only a few messages in chat monitor before it gets disconnected by core saying "didn't receive a heart beat for over 60 seconds". And I will then need to retry a few times before it finally stays connected.

Also maybe related, when I leave Quassel running over night, it usually is disconnected from core when I wake up. As well, when the CPU usage is high, Quassel sometimes gets disconnected from the core.

#2 Updated by ZRegis almost 15 years ago

Same problem for me (on protocol version 6) particularly when you are using unstable connection (aka as Wireless). You loose few packets, you loose the connection.

Sol 1: Provide a way to increase the heart beat time out.
Sol 2: beat more frequently and accept more missing beats.
Sol 3: Separate beat from data. Generally improve communication.

#3 Updated by Sputnick almost 15 years ago

  • Priority changed from High to Normal

#4 Updated by ZRegis almost 15 years ago

  • Target version set to 0.3.1

I think there is also a client issue on this point.

Please check that it's really a strong limitation, with an instable wireless connection.

#5 Updated by Sputnick almost 15 years ago

  • Status changed from New to Confirmed
  • Target version deleted (0.3.1)

Setting the target version to an already released version does not really make sense.

#6 Updated by EgS almost 15 years ago

  • Assignee set to EgS
  • Target version set to 0.4.0

Fixed in current git.;a=commitdiff;h=89e28856360c1d92ede38b97511ef711053f39a6

The SignalProxy uses the heart beats only as a last resort to check if
a peer is still alive. As long as data is received the signalproxy
will be happy.

Note: the client will still disconnect from the core if no data at all is received in 60 seconds. So if your core's load skyrockets, this won't help.

#7 Updated by EgS almost 15 years ago

  • Status changed from Confirmed to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF