Bugzilla

> I simply restarted TB after adding the PT-BR language. This made mail2_17.pop3 appear in the log.

I thought the logging prefix string (hard coded) was independent of localization, but I have never worked with language settings. I just changed it in the try build to identify the "try" version with date 2-17. 
Anyhow, it really didn't make a difference and failed even worse and timed out during the LIST processing and never even got to UIDL processing.

So at this point, the only thing I could suggest is that at startup you only have one POP3 account check for new mail. In comment 89 you show 7 accounts all checking for new mail at startup. Maybe if you only have one account (probably your main and largest account) check for mail at startup it would help. Also, having each account check for new mail on different times, as you now have it, is a good idea to avoid more than one account checking for new mail at the same time. Maybe keep all account's "check for new mail" times at least 5 minutes apart.

(In reply to Isaac Ribeiro from comment #91)
> I notice that "markMessages" always appears after "-ERR Connection is Closed. 12". Maybe deleting messages is blocking NOOPs from being sent.

I haven't really studies how POP3 deleting works in detail. But I've seen that when you delete a pop3 message from Inbox, it marks it as deleted in the popstate.dat file. Then only on the next restart are the messages actually deleted from the POP3 server (using POP3 "DELE" command). But I don't think the "markMessage" is blocking the NOOPs since it occurred well after the -ERR Connection is Closed.

What I've seen while testing here is that NOOPs or other POP3 commands are never sent if there is a lot of other activity going on, like quickly scrolling the messages list. In your case, the other background activities might be the other POP3 accounts checking for mail.

Note: With 102.15.1 (the last 102 version) scrolling the message list has no effect on POP3 commands getting sent yet with 115 and later it can completely stop POP3 activities.

> I simply restarted TB after adding the PT-BR language. This made mail2_17.pop3 appear in the log.

I thought the logging prefix string (hard coded) was independent of localization, but I have never worked with language settings. I just changed it in the try build to identify the "try" version with date 2-17. 
Anyhow, it really didn't make a difference and failed even worse and timed out during the LIST processing and never even got to UIDL processing.

So at this point, the only thing I could suggest is that at startup you only have one POP3 account check for new mail. In comment 89 you show 7 accounts all checking for new mail at startup. Maybe if you only have one account (probably your main and largest account) check for mail at startup it would help. Also, having each account check for new mail on different times, as you now have it, is a good idea to avoid more than one account checking for new mail at the same time. Maybe keep all account's "check for new mail" times at least 5 minutes apart.

(In reply to Isaac Ribeiro from comment #91)
> I notice that "markMessages" always appears after "-ERR Connection is Closed. 12". Maybe deleting messages is blocking NOOPs from being sent.

I haven't really studies how POP3 deleting works in detail. But I've seen that when you delete a pop3 message from Inbox, it marks it as deleted in the popstate.dat file. Then only on the next ~~restart~~ check for new messages are the messages actually deleted from the POP3 server (using POP3 "DELE" command). But I don't think the "markMessage" is blocking the NOOPs since it occurred well after the -ERR Connection is Closed.

What I've seen while testing here is that NOOPs or other POP3 commands are never sent if there is a lot of other activity going on, like quickly scrolling the messages list. In your case, the other background activities might be the other POP3 accounts checking for mail.

Note: With 102.15.1 (the last 102 version) scrolling the message list has no effect on POP3 commands getting sent yet with 115 and later it can completely stop POP3 activities.