Here are my observations about this problem:
1) POP Peeper will report several different errors, but they're all related to the same problem. For example:
- Error (send) -- this happens when the connection is broken but PP hasn't detected it yet, so it still tries to *send* a command.
- Timeout
- Bad connection
- SSL connection failed
2) I was looking at PP's code last night and I did discover a relevant problem; however, this is fairly insignificant. The problem I found is that PP is calculating the timeout incorrectly for IMAP. This is easier to explain via example:
- The default timeout for IMAP is 60s
- Say PP is expecting data from the server and it takes 10 seconds to receive the first byte of data, but is still expecting more data.
- There is then another lull in receiving the data
- PP will timeout in *50* seconds (because there was a combined timeout of 60s while expecting data)
-> what PP *should* do is reset the timeout counter after it receives the first bytes of data (so it would have timed out after a total of 70s). This means that data could be slowly sent and it could theoretically take minutes/hours/days without getting a "timeout" error as long as *some* amount of data is sent every 60s.
Even though PP is calculating the timeout incorrectly, I don't expect that it would have a significant impact on this issue. I happened to notice this behavior in the logs when I saw that I was getting a timeout sooner than what lined up with the timestamps, but when I was debugging it, this was never a contributing factor of the timeout.
3) I suspect that the servers are overloaded. Personally, I saw better results last night, but things are pretty bad again today. That is, Hotmail's servers may be busier during U.S. business hours as opposed to off-hours.
4) This seems to happen every once in a while with Hotmail/Outlook. Without looking for previous occurrences, I would say it happens 1-2 times a year and it eventually fixes itself after a week or so.
5) I've been testing with Thunderbird and it is not immune to the problem. One thing that it does differently from PP is that, if the connection is lost, it will immediately login and try again. Here's an actual log from TB (relevant lines only):
Code: Select all
Thunderbird log:
2017-03-31 19:30:59.464000 UTC - 7856[17dc2680]: 17de0000:imap-mail.outlook.com:NA:ProcessCurrentURL: entering
...
2017-03-31 19:31:47.975000 UTC - 7856[17dc2680]: 17de0000:imap-mail.outlook.com:S-INBOX:SendData: 9 UID fetch 1:* (FLAGS)
...
2017-03-31 19:31:50.332000 UTC - 7856[17dc2680]: 17de0000:imap-mail.outlook.com:S-INBOX:CreateNewLineFromSocket: * 226 FETCH (FLAGS (\Seen) UID 228)
2017-03-31 19:31:56.739000 UTC - 7856[17dc2680]: 17de0000:imap-mail.outlook.com:S-INBOX:CreateNewLineFromSocket: * 227 FETCH (FLAGS (\Seen) UID 229)
...
2017-03-31 19:31:56.739000 UTC - 7856[17dc2680]: 17de0000:imap-mail.outlook.com:S-INBOX:CreateNewLineFromSocket: * 260 FETCH (FLAGS (\Seen) UID 263)
2017-03-31 19:32:38.301000 UTC - 7856[17dc2680]: 17de0000:imap-mail.outlook.com:S-INBOX:CreateNewLineFromSocket: * 261 FETCH (FLAGS (\Seen) UID 264)
...
2017-03-31 19:32:39.349000 UTC - 7856[17dc2680]: 17de0000:imap-mail.outlook.com:S-INBOX:CreateNewLineFromSocket: 9 OK FETCH completed.
...
2017-03-31 19:32:42.872000 UTC - 7856[17dc2680]: 17de0000:imap-mail.outlook.com:S-INBOX:TellThreadToDie: close socket connection
Ok, the relevant information:
- The entirety took 103 seconds. There were no new messages, just a simple check. On a normal day/server, this should take a few seconds.
- The log only shows one internal command, which is a typical "fetch" to see what messages are currently on the server. The lines I'm including above show that there were 2 significant breaks waiting for information (31:50-31:56 and 31:56-32:38). My inbox only has 406 messages; so this could be much worse with more messages (and why I recommend removing messages). In fact, this actually contradicts what I said earlier about the way that PP is incorrectly calculating the timeout probably isn't relevant. I've added information about the timeout below.
Here are some suggestions to try to reduce the problems:
- If you can reduce the number of messages in your inbox, that may be very helpful. And by "reduce" I mean empty. Move all your inbox messages into another folder using your webbrowser.
- Increasing the IMAP timeout may help reduce the errors. POP Peeper's default for IMAP is 60 seconds. Because of the way that PP is currently miscalculating the timeout, I'm recommending a higher timeout than I would normally suggest -- say 180 or even 300. To change the timeout:
main menu: Tools / PPtweaker; 'Connection' page; "Timeout for POP3 and IMAP"
- If you have a string of consecutive errors, exiting and restarting POP Peeper may help
- You *may* have better luck using Webmail or POP3. Bear in mind, some people have mentioned that the other protocols have also had issues (just not as much), and when you change the protocol in PP, PP will have to re-download all existing messages.