This sometimes happens: click on a folder, and then claws starts reindexing the folder, instead of showing its contents. At the times I've observed this, I've always had enough free disk space and there was nothing else unusual. It seems sometimes reindexing never terminates and just restarts once its done (can't be sure). I usually kill -9 claws when it's doing that - after restart, it usually doesn't want to reindex anymore and shows the folder contents instantly. This is the most frequent reason why I kill -9 claws regularly (usually a few times a day).
then wait a bit?
>then wait a bit? Are you trolling?
(In reply to comment #2) > Are you trolling? seems more like you are. why not try to discuss issues first via the usual channels, rather than bombarding the bug tracker with your nitpicking?
Nitpicking? I'm just documenting all issues I've had with this email client, after I've used it for month. I tried the IRC channel long ago, but was met with disinterest and "patches welcome". I don't know what else you could mean with "usual channels". This is a bug tracker, meant for bug reports, right? Where else should I report bugs? If development is this stale that you won't even accept bugs and just mark them as invalid, I suggest closing the bug tracker. Anyway, this is a real issue. Please don't close it just because you don't understand it.
(In reply to comment #4) > Nitpicking? Sure. Some of them are simply that. > I'm just documenting all issues I've had with this email client, > after I've used it for month. I tried the IRC channel long ago, but was met > with disinterest and "patches welcome". I don't know what else you could > mean with "usual channels". That's vague. I don't remember you. > This is a bug tracker, meant for bug reports, > right? Where else should I report bugs? Well, I don't think you're in a position to decide how this should be used. We have a way of doing things. I ask you to comply. > If development is this stale that > you won't even accept bugs and just mark them as invalid, I suggest closing > the bug tracker. Thanks for your suggestion, I won't be be acting on it. Quick replies here dont suggest any staleness to me. > Anyway, this is a real issue. Please don't close it just because you don't > understand it. It's up to you as bug reported to report in such a way that it can be understood. So, please explain better. Perhaps start with explaining what you mean by "for no reason" in your summary.
>So, please explain better. It seems to happen if you click on a folder. There is no obvious or visible reason why it would do that. During indexing, the client is largely unresponsive, and AFAIR will deadlock sooner or later. These days I just kill -9 claws when it does this; after restart it does not want to index anymore (most times), so I assume there really is no reason for it to have initiated indexing in the previous instance. That's all I know. I don't know IMAP or claws internals, so that is all I can say.
I confirm this bug, it affects me too. This existed at least before 3.9. I use GMail and have a lot of messages in my inbox. The indexing takes several minutes. Sometimes instead of opening the next unread message (sorry, I didn't notice if I clicked the folder or just the message) I get the whole inbox redownloaded and reindexed. This happens without any obvious reason and not always (about every 10th message or such) and is very annoying. I haven't found any specific thing that triggers this behavior, but it seems to be more likely when a lot of new messages appear together. Some time ago I stopped using claws-mail for a while due to this bug. Now I'm using claws-mail again. Not sure if this bug still exists as I haven't received too many emails at these days. How to reproduce: sorry, I haven't found any easy way yet, so I just describe what I'm doing on a regular basis. having a GMail inbox of ~30000 messages, let somebody send you several dozens of emails. Then click on every new message and answer most of them. It's very likely that you'll have to wait several times due to reindexing. Being a software developer but unfamiliar with claws-mail internals, I could suspect that it has something to do with GMail IMAP IDs. This error never occured on a corporate mailbox, only on GMail, so I suspect that this is a bug in GMail IMAP implementation that triggers a bug in claws-mail.
Hi I am affected by this issue as well. By a long time now. Its not so frequent here but it happens at least once a month. I am not using Gmail. I use my own qmail SMTP/IMAP server. I could not spot what specificaly triggers it, but I agree that it only happens when you click on another folder. It takes CM dozens of minutes (almost one hour) to rescan the folder with 4500 or so mails. CM firstly performs a "not so fast" scan and then a slow scan, I think downloading (or visiting) all messages bodies. "Network window" does not show any significant info. Just thousands of "IMAP4< [FETCH data - 8192 bytes]" lines. How can we help you guys to spot this? Perharps a debug switch can be implemented to collect intell?
sounds something like bug #3049 can you attach the debug?
(In reply to comment #9) > sounds something like bug #3049 > can you attach the debug? I should add: make sure that's with version 3.11.0
Hello, (In reply to comment #10) > I should add: make sure that's with version 3.11.0 I would really like to upgrade from 3.10.1 to 3.11.0. But I currently am using the Win32 version and there still is no update available for it: http://www.claws-mail.org/win32/ So, when will the Win32 version be updated? It would be much appreciated if you could release an update for Win32 ASAP, especially considering POODLE and so on. Regards
I'm also affected by this bug, and like the initial reporter, I also kill -9 claws-mail regularly because of this, which is quite annoying. My setup is IMAP, with fairly large (10+k e-mails) folders. I'm running 3.11.1 on Linux, and this bug has been present since a long time.
Sure its related to indexing? I get those errors when I have a few (3k) mails in my inbox and run my ~20 Processing Rules over that. Processing seems to run until the end but claws mail won't update the gui during that process. Especially rules with big address books attached to their processing (e.g. if adr in book) seem to keep it working alot. Claws-Mail: 3.11.1 Debian Stable thanks for this great software and greetings
Looks like I am also affected by this issue. Version 3.17.8 Interestingly it seems as it got worse with the time I use it (~6 month). During these episodes, log shows thousands of "FETCH data" messages, and the application is unresponsive. For me, it happens with very large folders, but not only gmail.
see bug #4602 comment #2 for the potential solution.
*** This bug has been marked as a duplicate of bug 4602 ***