Profanity: Incredibly bad lag to the point of unusability

[kozross]

I'm trying to use Profanity to chat to people on my XMPP server. However, I get incredibly awful spikes of lag, lasting nearly minutes at a time, after which the input suddenly 'catches up'. This makes it near-unusable,and I'm completely unclear as to why it happens.

[decentral1se]

Sounds like the network and not the client. Any insights on your bandwidth?

[kozross]

This was happening relative a server on my LAN. Additionally, I have used the same server with Conversations on a mobile network without lag anything like this. It's _definitely_ not the network's problem.

[decentral1se]

OK, well, can you bring any additional information for the bug report?

It's not possible to do anything in the current state. Versions, debug log, something else?

[jubalh]

I have not experienced such behaviour or heard of anyone else experiencing it.

Please provide more information if the problem still exists.
Will close for now. Feel free to reopen with more infos.

[nulani38728]

I am experiencing something like the above and would like some guidance on how to better debug the issue.

Client OS: arch linux with 5.7.12 kernel
Host software: prosody 0.11.5

profanity version: 0.9.5
Build information:
XMPP library: libmesode
Desktop notification support: Enabled
OTR support: Enabled (libotr 4.1.1)
PGP support: Enabled (libgpgme 1.14.0)
OMEMO support: Enabled
C plugins: Enabled
Python plugins: Enabled (3.8.3)
GTK icons: Disabled

The host does not use OTR or any elaborate settings at the moment and adheres to sane defaults. There are only 3 users.

When another user sends a message to a user on the profanity client, the profanity client hangs for 30-60 seconds (hard freeze, cannot interact with the application) until "catching up" and displaying the incoming message. Every time a new message or presence update is sent, the same thing occurs.

On other (seemingly all) XMPP clients, the issue is not present, and users can communicate in real time with no delay. I have also reproduced the above "hanging" issue by myself connecting as multiple users on profanity and other clients and sending messages between them. When profanity is the recipient, the hang always occurs. I do not suspect a network issue at this time (unless there is a network-specific flag I need to set somewhere in profanity? Already experimented with ping intervals to no avail).

Complicating matters is the fact that the command profanity -l DEBUG is not producing any log file, nor does the -f flag for writing to a different logfile seem to work.

Could you please advise on how to correctly generate log files and what parts to look for in these logs? Please let me know if I forgot to include any details.

[jubalh]

When another user sends a message to a user on the profanity client, the profanity client hangs for 30-60 seconds (hard freeze, cannot interact with the application) until "catching up" and displaying the incoming message. Every time a new message or presence update is sent, the same thing occurs.

So you have one instance of Profanity running on your PC and and someone sends you a message and this happens?
Did you compile Profanity yourself or got it from AUR?

Complicating matters is the fact that the command profanity -l DEBUG is not producing any log file, nor does the -f flag for writing to a different logfile seem to work.

Log files are saved in ~/.local/share/profanity/logs. Did you actually check in there?

@pasis any idea how this could happend or what info we would need?

[jubalh]

https://profanity-im.github.io/issues.html is explaining where the logfile is located btw.

[nulani38728]

Thank you for the quick reply.

Firstly, allow me to apologize for what was partially user error. I had a PEBCAK moment and in spite of reading the help file over and over again, misread the location to be XDG_CONFIG_HOME instead of XDG_DATA_HOME. (Don't ask why.)

Okay, so I got the logs, and I think I see what is happening.

When a RECV event from an incoming message is created, the message text is captured immediately.
The program by default ships with desktop notifications enabled.
After getting the message, the client tries to trigger libnotify to send a desktop notification.

//message received from another user at 16:03:48, names etc redacted

07/07/2020 16:03:48: xmpp: DBG: RECV: <message id="redacted" to="redacted" type="chat" from="redacted"><body>SENDING TEST MESSAGE</body></message>
07/07/2020 16:03:48: prof: DBG: Message stanza handler fired

//notification is attempted

07/07/2020 16:03:48: prof: DBG: Attempting notification:  redacted (win 2)
SENDING TEST MESSAGE
07/07/2020 16:03:48: prof: DBG: Reinitialising libnotify

//time passes (25s) ...libnotify times out

07/07/2020 16:04:13: prof: ERR: Error sending desktop notification:
07/07/2020 16:04:13: prof: ERR:   -> Message :  redacted (win 2)
SENDING TEST MESSAGE
07/07/2020 16:04:13: prof: ERR:   -> Error   : Error calling StartServiceByName for org.freedesktop.Notifications: Timeout was reached

As you can see above, libnotify is called, and this times out after not receiving the expected response.
This freezes up the whole client until the timeout and the held message is released, even though the message was already received at the expected time.

Interestingly, this also has the unintended side effect of causing you to become disconnected repeatedly from the server if the client is frozen longer than the autoping interval (which is likely).

While I do have the libnotify library on my system, I don't have desktop notifications, a tray, or a global notification server enabled. Out of the box, profanity depends on libnotify, as do several other commonly installed applications (I see ibus and zenity in the list when cross-checking dependencies).

After checking /prefs desktop, I disabled chat and room notifications for a start, and this was enough to stop the behavior from recurring.

I feel this is kind of opaque to the user, given the obscurity of the flag required to turn it off, and the fact that it's enabled by default and the application assumes there will be a notification server or daemon running. I guess building profanity from source would be another solution, but that seems a bit extreme for this sort of scenario. Incidentally, profanity is available in Arch's upstream packages, so it doesn't have to be fetched from the AUR and built.

Fortunately, the logs are clear, so the problem is easy enough to discover. Should there be some fallback mechanism to test for the presence of a notification daemon at boot and disable these flags? Warn the user? Or better, decouple the notification from the receive message action? It seems problematic that the message (and the client) is held in limbo while we wait for a timeout response that may or may not come, rather than the notification timing out in the background.

[jubalh]

Nice! Great that you discovered the root cause of this!
Maybe the people who commented here earlier can check whether this is the same for them?

I'll try to fix this once I have some time!

[nulani38728]

Thank you very much!

[jubalh]

While I do have the libnotify library on my system, I don't have desktop notifications, a tray, or a global notification server enabled. Out of the box, profanity depends on libnotify, as do several other commonly installed applications (I see ibus and zenity in the list when cross-checking dependencies).

To my knowledge, and after checking https://developer.gnome.org/libnotify/unstable/ch01.html, I don't see a way to detect whether a notification server is running.

I guess building profanity from source would be another solution, but that seems a bit extreme for this sort of scenario.

Building with --disable-notifications will disable them totally. We can't control what each distro sets as default.

I feel this is kind of opaque to the user, given the obscurity of the flag required to turn it off, and the fact that it's enabled by default and the application assumes there will be a notification server or daemon running.

True.

1. Find a way to detect whether a notification server is running
2. Run our notify() function in a thread (need to copy the message string and free internally). But this has the disadvantage to waste many thread each time a person just types. So for all the users who have their system set up properly this is a disadvantage just to save the ones that didn't set up their system properly.
3. Disable notifications by default. So if a user chooses to enable it himself, and doesn't have a notifications daemon running (probably a minority) it's their responsibility to check the logs and find the problem. And for the others it will just work.

I guess if we cant do 1, then 3 is the best alternative.