Greetings all;
So I picked the largest cur dirs, and using mc have moved about 2 years worth of each to an outside of the ~/Mail view of kmail. And nuked those index files, so it has to rebuild them. Its not done with that yet, but we'll see. Damn this is getting old.
Cheers, Gene Heskett
On Friday 13 December 2019 11:52:09 Gene Heskett wrote:
Greetings all;
So I picked the largest cur dirs, and using mc have moved about 2 years worth of each to an outside of the ~/Mail view of kmail. And nuked those index files, so it has to rebuild them. Its not done with that yet, but we'll see. Damn this is getting old.
Cheers, Gene Heskett
The complete corpus of my Kmail (including nearly 20 years of archives like yourself) is only about 4.5 gb, and my machine is built out of spare parts, most of which are older than Utnapishtim's Flood. And while my machine is a little slow sometimes, I never experience anything like you keep describing.
I hope to get myself an SSD to install as my home directory, which ought to speed things up for me, at least.
It is a problem of diminishing returns: you want to have those archives available somewhere, to find information that you saved, but now the size of those archives is making Kmail unusable. So I would say, keep pruning until it stops misbehaving. You will still have those old emails available, so long as they are removed to where Kmail won't look. They can always be retrieved if you really need them.
Bill
On Friday 13 December 2019 03:05:18 pm William Morder via trinity-users wrote:
I hope to get myself an SSD to install as my home directory, which ought to speed things up for me, at least.
I've found it better to use the SSD for whatever the computer boots from. For things like rootfs and swap. If you can add /home to that as well that's also good. Then spindisks somewhere else for bulk storage. (I always use to use /data/drive, but /media/username/drive seems the new norm for automount?)
HTH, Michael
On Friday 13 December 2019 14:25:09 Michael wrote:
On Friday 13 December 2019 03:05:18 pm William Morder via trinity-users
wrote:
I hope to get myself an SSD to install as my home directory, which ought to speed things up for me, at least.
I've found it better to use the SSD for whatever the computer boots from. For things like rootfs and swap. If you can add /home to that as well that's also good. Then spindisks somewhere else for bulk storage. (I always use to use /data/drive, but /media/username/drive seems the new norm for automount?)
HTH, Michael
Yes, that was my intention. I might eventually get into some fancier partitioning, but for now I keep my home directory on the same drive as / (and everything in it, such as the boot partition). I don't use my home partition for saving anything other than very limited, temporary items. Otherwise, I move everything to other drives. That way, if something bad happens, I don't lose everything.
I don't need a big drive for my / and /home, and I see that I can buy SSDs on Amazon for cheap. I saw a Samsung 500 gb SSD for about $60. My current "home" hard drive is only 100 gb, with four serial SATA drives and two external drives. Next is to get a bigger external hdd, as my present storage situation is getting critical, down to megabytes in some cases, so I need to redistribute the archives. (Note that I seem to have Gene's problem with "too much stuff", just that it manifests in a different way.)
Any recommendations on best SSDs (most dependable, best value, etc.) would be welcome, as I only know them by reputation, not from experience.
Bill
On Friday 13 December 2019 04:53:53 pm William Morder via trinity-users wrote:
On Friday 13 December 2019 14:25:09 Michael wrote:
On Friday 13 December 2019 03:05:18 pm William Morder via trinity-users
Any recommendations on best SSDs (most dependable, best value, etc.) would be welcome, as I only know them by reputation, not from experience.
Last I bought was an m.2(Samsung 970 EVO SSD 1TB - M.2 NVMe), so that's no help for you :( I use this when buying a new drive:
https://www.harddrivebenchmark.net/ssd.html
But it's now hard to filter out form factor (I'm assuming you're looking for SATA 6 Gbit/s not m.2), and actually that looks like it's only m.2 form factor now.
Try this:
https://www.harddrivebenchmark.net/hdd-mega-page.html
Select SSD, sort by Disk Mark and drop below ???
Nevermind, PassMark has made that completely useless :(!
# # #
If you just want one that will do you well, try this for $60:
https://www.amazon.com/Samsung-500GB-Internal-MZ-76E500B-AM/dp/B0781Z7Y3S
If you can afford $50 more, bump it up to the 1TB version...
Best, and hope that helps, Michael
PS: Do get a SATA 6 Gbit/s SSD even if you MB only has SATA 3 Gbit/s connections, stupidly that about doubles the transfer speeds. (I'll guess the 3 Gbit/s SSDs have crappy internals, 'cause they can.)
On Friday 13 December 2019 16:05:18 William Morder via trinity-users wrote:
On Friday 13 December 2019 11:52:09 Gene Heskett wrote:
Greetings all;
So I picked the largest cur dirs, and using mc have moved about 2 years worth of each to an outside of the ~/Mail view of kmail. And nuked those index files, so it has to rebuild them. Its not done with that yet, but we'll see. Damn this is getting old.
Cheers, Gene Heskett
The complete corpus of my Kmail (including nearly 20 years of archives like yourself) is only about 4.5 gb, and my machine is built out of spare parts, most of which are older than Utnapishtim's Flood. And while my machine is a little slow sometimes, I never experience anything like you keep describing.
I started a year ago with over 12GB but my moving of older stuff out of the Mail directory has now reduced the "du -h Mail" to about 4.8GB. I've stopped kmail 4 or 5 times, but on the restart, and that nearly always crashes once, but before it crashes, maybe 3 seconds elapsed, it has pulled all the "index" files out of cache someplace I haven't found. So I nuked ALL the index files 3 times. Then it crashed about 2-3 seconds after startup each time.
A 4th or 5th restart has not crashed, and it updated the dates on ALL index files twice, then has shut that off again. The largest remaining directory now is "sent-mail" and its way bigger than any of the rest by a factor of at least 2. So momentarily, its behaving itself. 2 hours? a week, a year, the rapture? who knows???
Its a bit like asking, while concrete is being poured, if it will crack? Wrong question, not if, its when, if properly formed as a question. :)
I hope to get myself an SSD to install as my home directory, which ought to speed things up for me, at least.
Haveing done that to the boot drive in one of my milling machines, I can testify that an old pentium powered Dell, pulling from the sata SSD, is a good 10x faster than when it was loading from spinning rust. Amazing.
It is a problem of diminishing returns: you want to have those archives available somewhere, to find information that you saved, but now the size of those archives is making Kmail unusable. So I would say, keep pruning until it stops misbehaving. You will still have those old emails available, so long as they are removed to where Kmail won't look. They can always be retrieved if you really need them.
Bill
Take care Bill.
Cheers, Gene Heskett
On Friday 13 December 2019 19:49:35 Gene Heskett wrote:
On Friday 13 December 2019 16:05:18 William Morder via trinity-users
wrote:
On Friday 13 December 2019 11:52:09 Gene Heskett wrote:
Greetings all;
So I picked the largest cur dirs, and using mc have moved about 2 years worth of each to an outside of the ~/Mail view of kmail. And nuked those index files, so it has to rebuild them. Its not done with that yet, but we'll see. Damn this is getting old.
Cheers, Gene Heskett
The complete corpus of my Kmail (including nearly 20 years of archives like yourself) is only about 4.5 gb, and my machine is built out of spare parts, most of which are older than Utnapishtim's Flood. And while my machine is a little slow sometimes, I never experience anything like you keep describing.
I started a year ago with over 12GB but my moving of older stuff out of the Mail directory has now reduced the "du -h Mail" to about 4.8GB. I've stopped kmail 4 or 5 times, but on the restart, and that nearly always crashes once, but before it crashes, maybe 3 seconds elapsed, it has pulled all the "index" files out of cache someplace I haven't found. So I nuked ALL the index files 3 times. Then it crashed about 2-3 seconds after startup each time.
A 4th or 5th restart has not crashed, and it updated the dates on ALL index files twice, then has shut that off again. The largest remaining directory now is "sent-mail" and its way bigger than any of the rest by a factor of at least 2. So momentarily, its behaving itself. 2 hours? a week, a year, the rapture? who knows???
Its a bit like asking, while concrete is being poured, if it will crack? Wrong question, not if, its when, if properly formed as a question. :)
I hope to get myself an SSD to install as my home directory, which ought to speed things up for me, at least.
Haveing done that to the boot drive in one of my milling machines, I can testify that an old pentium powered Dell, pulling from the sata SSD, is a good 10x faster than when it was loading from spinning rust. Amazing.
It is a problem of diminishing returns: you want to have those archives available somewhere, to find information that you saved, but now the size of those archives is making Kmail unusable. So I would say, keep pruning until it stops misbehaving. You will still have those old emails available, so long as they are removed to where Kmail won't look. They can always be retrieved if you really need them.
Bill
Take care Bill.
Cheers, Gene Heskett
Stupid question: Do you compact email folders? or does Kmail do that for you automatically every so periodically often? Mine is a little of both; if Kmail doesn't do it, then I compact them manually.
Bill
On Saturday 14 December 2019 00:27:53 William Morder via trinity-users wrote:
On Friday 13 December 2019 19:49:35 Gene Heskett wrote:
On Friday 13 December 2019 16:05:18 William Morder via trinity-users
wrote:
On Friday 13 December 2019 11:52:09 Gene Heskett wrote:
Greetings all;
So I picked the largest cur dirs, and using mc have moved about 2 years worth of each to an outside of the ~/Mail view of kmail. And nuked those index files, so it has to rebuild them. Its not done with that yet, but we'll see. Damn this is getting old.
Cheers, Gene Heskett
The complete corpus of my Kmail (including nearly 20 years of archives like yourself) is only about 4.5 gb, and my machine is built out of spare parts, most of which are older than Utnapishtim's Flood. And while my machine is a little slow sometimes, I never experience anything like you keep describing.
I started a year ago with over 12GB but my moving of older stuff out of the Mail directory has now reduced the "du -h Mail" to about 4.8GB. I've stopped kmail 4 or 5 times, but on the restart, and that nearly always crashes once, but before it crashes, maybe 3 seconds elapsed, it has pulled all the "index" files out of cache someplace I haven't found. So I nuked ALL the index files 3 times. Then it crashed about 2-3 seconds after startup each time.
A 4th or 5th restart has not crashed, and it updated the dates on ALL index files twice, then has shut that off again. The largest remaining directory now is "sent-mail" and its way bigger than any of the rest by a factor of at least 2. So momentarily, its behaving itself. 2 hours? a week, a year, the rapture? who knows???
Its a bit like asking, while concrete is being poured, if it will crack? Wrong question, not if, its when, if properly formed as a question. :)
I hope to get myself an SSD to install as my home directory, which ought to speed things up for me, at least.
Haveing done that to the boot drive in one of my milling machines, I can testify that an old pentium powered Dell, pulling from the sata SSD, is a good 10x faster than when it was loading from spinning rust. Amazing.
It is a problem of diminishing returns: you want to have those archives available somewhere, to find information that you saved, but now the size of those archives is making Kmail unusable. So I would say, keep pruning until it stops misbehaving. You will still have those old emails available, so long as they are removed to where Kmail won't look. They can always be retrieved if you really need them.
Bill
Take care Bill.
Cheers, Gene Heskett
Stupid question: Do you compact email folders? or does Kmail do that for you automatically every so periodically often? Mine is a little of both; if Kmail doesn't do it, then I compact them manually.
Bill
kmail does, I don't as a general rule. I'll see if I can do that, it might just shrink the index files.
Thanks Bill.
Cheers, Gene Heskett
On Saturday 14 December 2019 01:38:27 Gene Heskett wrote:
On Saturday 14 December 2019 00:27:53 William Morder via trinity-users
wrote:
On Friday 13 December 2019 19:49:35 Gene Heskett wrote:
On Friday 13 December 2019 16:05:18 William Morder via trinity-users
wrote:
On Friday 13 December 2019 11:52:09 Gene Heskett wrote:
Greetings all;
So I picked the largest cur dirs, and using mc have moved about 2 years worth of each to an outside of the ~/Mail view of kmail. And nuked those index files, so it has to rebuild them. Its not done with that yet, but we'll see. Damn this is getting old.
Cheers, Gene Heskett
The complete corpus of my Kmail (including nearly 20 years of archives like yourself) is only about 4.5 gb, and my machine is built out of spare parts, most of which are older than Utnapishtim's Flood. And while my machine is a little slow sometimes, I never experience anything like you keep describing.
I started a year ago with over 12GB but my moving of older stuff out of the Mail directory has now reduced the "du -h Mail" to about 4.8GB. I've stopped kmail 4 or 5 times, but on the restart, and that nearly always crashes once, but before it crashes, maybe 3 seconds elapsed, it has pulled all the "index" files out of cache someplace I haven't found. So I nuked ALL the index files 3 times. Then it crashed about 2-3 seconds after startup each time.
A 4th or 5th restart has not crashed, and it updated the dates on ALL index files twice, then has shut that off again. The largest remaining directory now is "sent-mail" and its way bigger than any of the rest by a factor of at least 2. So momentarily, its behaving itself. 2 hours? a week, a year, the rapture? who knows???
Its a bit like asking, while concrete is being poured, if it will crack? Wrong question, not if, its when, if properly formed as a question. :)
I hope to get myself an SSD to install as my home directory, which ought to speed things up for me, at least.
Haveing done that to the boot drive in one of my milling machines, I can testify that an old pentium powered Dell, pulling from the sata SSD, is a good 10x faster than when it was loading from spinning rust. Amazing.
It is a problem of diminishing returns: you want to have those archives available somewhere, to find information that you saved, but now the size of those archives is making Kmail unusable. So I would say, keep pruning until it stops misbehaving. You will still have those old emails available, so long as they are removed to where Kmail won't look. They can always be retrieved if you really need them.
Bill
Take care Bill.
Cheers, Gene Heskett
Stupid question: Do you compact email folders? or does Kmail do that for you automatically every so periodically often? Mine is a little of both; if Kmail doesn't do it, then I compact them manually.
Bill
kmail does, I don't as a general rule. I'll see if I can do that, it might just shrink the index files.
No noticeable diff, whole maryann is still 4.8GB
Thanks Bill.
Cheers, Gene Heskett
Cheers, Gene Heskett
On Saturday 14 December 2019 01:47:01 Gene Heskett wrote:
On Saturday 14 December 2019 01:38:27 Gene Heskett wrote:
On Saturday 14 December 2019 00:27:53 William Morder via trinity-users
wrote:
On Friday 13 December 2019 19:49:35 Gene Heskett wrote:
On Friday 13 December 2019 16:05:18 William Morder via trinity-users
wrote:
On Friday 13 December 2019 11:52:09 Gene Heskett wrote:
Greetings all;
So I picked the largest cur dirs, and using mc have moved about 2 years worth of each to an outside of the ~/Mail view of kmail. And nuked those index files, so it has to rebuild them. Its not done with that yet, but we'll see. Damn this is getting old.
Cheers, Gene Heskett
The complete corpus of my Kmail (including nearly 20 years of archives like yourself) is only about 4.5 gb, and my machine is built out of spare parts, most of which are older than Utnapishtim's Flood. And while my machine is a little slow sometimes, I never experience anything like you keep describing.
I started a year ago with over 12GB but my moving of older stuff out of the Mail directory has now reduced the "du -h Mail" to about 4.8GB. I've stopped kmail 4 or 5 times, but on the restart, and that nearly always crashes once, but before it crashes, maybe 3 seconds elapsed, it has pulled all the "index" files out of cache someplace I haven't found. So I nuked ALL the index files 3 times. Then it crashed about 2-3 seconds after startup each time.
A 4th or 5th restart has not crashed, and it updated the dates on ALL index files twice, then has shut that off again. The largest remaining directory now is "sent-mail" and its way bigger than any of the rest by a factor of at least 2. So momentarily, its behaving itself. 2 hours? a week, a year, the rapture? who knows???
Its a bit like asking, while concrete is being poured, if it will crack? Wrong question, not if, its when, if properly formed as a question. :)
I hope to get myself an SSD to install as my home directory, which ought to speed things up for me, at least.
Haveing done that to the boot drive in one of my milling machines, I can testify that an old pentium powered Dell, pulling from the sata SSD, is a good 10x faster than when it was loading from spinning rust. Amazing.
It is a problem of diminishing returns: you want to have those archives available somewhere, to find information that you saved, but now the size of those archives is making Kmail unusable. So I would say, keep pruning until it stops misbehaving. You will still have those old emails available, so long as they are removed to where Kmail won't look. They can always be retrieved if you really need them.
Bill
Take care Bill.
Cheers, Gene Heskett
Stupid question: Do you compact email folders? or does Kmail do that for you automatically every so periodically often? Mine is a little of both; if Kmail doesn't do it, then I compact them manually.
Bill
kmail does, I don't as a general rule. I'll see if I can do that, it might just shrink the index files.
No noticeable diff, whole maryann is still 4.8GB
Thanks Bill.
Went to bed at 1:50, up to pee at 5:20, its back again. Since sent-mail was the biggest, I went to the OldMail dir wih mc and created a new old.sent.mail/cur there and moved the first half of the first year of sent-mail/cur to it.
stopped kmail renamed/moved sent-mail/cur to old.sent.mail/gene made a new sent-mail/cur copied old.sent.mail/gene* to sent-mail/cur/ deleted old.sent.mail.gene
This should have given a newer, shorter directory with no blank spots from me moving stuff early in the directory out, leaving tons of empty space.
Restarted kmail, which took a long time to open its gui but hasn't crashed yet. The regenerated sent-mail/cur now has a much shorter set of index files. And it indexed it once and shut the indexing off, but must have had to think about it as it just started up again. And I think what I'm seeing now for an ls -la Mail is from the cache, no files dates have changed in 6 minutes, but its still hammering away. And finally, after 14 minutes, updated the times of the debian folders index's. At this rate, probably another 30 minutes to do the 2nd full scan.
I am reading each cores temp individually with gkrellm and its switching cores when the individual core hits 50C.
I think if this helps, I probably should do the cur rewrite to shorten the dir file as above on all the curs that have been divided into subdirs.
But, I don't think it helped. Its still hammering away, but hasn't updated an index file in over 20 minutes. I may as well send this and go catch up on my sleep.
Cheers, Gene Heskett
Gene Heskett wrote:
But, I don't think it helped. Its still hammering away, but hasn't updated an index file in over 20 minutes. I may as well send this and go catch up on my sleep.
Just found in the configuration options of KMail under (perhaps "Others") there is "Enable full text indexing". Is it checked for you by chance?
What happens if unchecked?
On Sunday 15 December 2019 06:32:56 deloptes wrote:
Gene Heskett wrote:
But, I don't think it helped. Its still hammering away, but hasn't updated an index file in over 20 minutes. I may as well send this and go catch up on my sleep.
Just found in the configuration options of KMail under (perhaps "Others") there is "Enable full text indexing". Is it checked for you by chance?
What happens if unchecked?
It stops instantly. THANK YOU VERY VERY MUCH, deloptes. I owe you a hand cooler or 2 but you'll have to come and get it cuz I've no clue where to send it. I am in North Central WV, USA.
I don't recall checking it. Presumably this should make message searching faster? Next Q of course is when will it self check itself again?
This is slightly reminiscent of the sticky buttons at the upper right of the composer's screen. The entries they are supposed to lock are still subject to random editing that I don't do, so I sometimes have to go look thru the whole MaryAnn and move my sent-mail back to the sent-mail folder. Or restore some other setting that S/B set and forget. Last week it was go get about 10 days worth of sent-mail from this lists folder. Anything in that 4 line header is apparently subject to being randomly set to anything in its menu without a specific action from me. And the "sticky" buttons are indeed checked. Makes me compare their effectiveness to the appendages on a boar hogs belly,.. Despite being checked, I can select and set them, all 4 of them from the multiselector menu with a left click anyplace on that line.
Can a bug be filed on that? Composer "sticky" buttons don't work?
Thanks again deloptes, I do believe that was it. Does the handbook mention this? Theres a fairly long list that I've not collated over the last 20 years. Most glaring is its inability to go get new mail in the background, which caused me to offload that to fetchmail-procmail and a chain of spam and viri catchers. All synchronized by inotifywait. I used to yell at Ingo K. over some of the more glaring ones till I figured our he was attempting to herd cats. And wasn't that good at it. ;-)
Cheers, Gene Heskett
Anno domini 2019 Sun, 15 Dec 10:14:38 -0500 Gene Heskett scripsit:
On Sunday 15 December 2019 06:32:56 deloptes wrote:
Gene Heskett wrote:
But, I don't think it helped. Its still hammering away, but hasn't updated an index file in over 20 minutes. I may as well send this and go catch up on my sleep.
Just found in the configuration options of KMail under (perhaps "Others") there is "Enable full text indexing". Is it checked for you by chance?
What happens if unchecked?
It stops instantly. THANK YOU VERY VERY MUCH, deloptes. I owe you a hand cooler or 2 but you'll have to come and get it cuz I've no clue where to send it. I am in North Central WV, USA.
I don't recall checking it. Presumably this should make message searching faster? Next Q of course is when will it self check itself again?
This is slightly reminiscent of the sticky buttons at the upper right of the composer's screen. The entries they are supposed to lock are still subject to random editing that I don't do, so I sometimes have to go look thru the whole MaryAnn and move my sent-mail back to the sent-mail folder. Or restore some other setting that S/B set and forget. Last week it was go get about 10 days worth of sent-mail from this lists folder. Anything in that 4 line header is apparently subject to being randomly set to anything in its menu without a specific action from me. And the "sticky" buttons are indeed checked. Makes me compare their effectiveness to the appendages on a boar hogs belly,.. Despite being checked, I can select and set them, all 4 of them from the multiselector menu with a left click anyplace on that line.
Can a bug be filed on that? Composer "sticky" buttons don't work?
Thanks again deloptes, I do believe that was it. Does the handbook mention this? Theres a fairly long list that I've not collated over the last 20 years. Most glaring is its inability to go get new mail in the background, which caused me to offload that to fetchmail-procmail and a chain of spam and viri catchers. All synchronized by inotifywait. I used to yell at Ingo K. over some of the more glaring ones till I figured our he was attempting to herd cats. And wasn't that good at it. ;-)
Cheers, Gene Heskett
:)
I realize it's not very thoughtful and caring of me, but I was hoping this would go on long enough to see just how long
Subject : Re: [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] kmail forever indexing is back
could grow before we saw some breakage somewhere. :-)
Jonesy
Marvin Jones via trinity-users wrote:
I realize it's not very thoughtful and caring of me, but I was hoping this would go on long enough to see just how long
Subject : Re: [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] kmail forever indexing is back
could grow before we saw some breakage somewhere. :-)
Sorry that we disappointed you.
On Sunday 15 December 2019 09:10:01 Marvin Jones via trinity-users wrote:
I realize it's not very thoughtful and caring of me, but I was hoping this would go on long enough to see just how long
Subject : Re: [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] kmail forever indexing is back
could grow before we saw some breakage somewhere. :-)Jonesy
I was hoping that we could somehow work in that place-name of a Welsh village (just saw it again the other day): something like 116 letters long, mostly Ls and Hs and Ws.
It has been taken up by various persons online who want to create the world's longest domain name.
Soon other mailing lists will have Subject Line Envy.
Bill
On Sun, 15 Dec 2019 10:10:01 -0700 (MST) "Marvin Jones via trinity-users" trinity-users@lists.pearsoncomputing.net wrote:
I realize it's not very thoughtful and caring of me, but I was hoping this would go on long enough to see just how long
Subject : Re: [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] [trinity-users] Re: [BULK] Re: [trinity-users] Re: [BULK] Re: [trinity-users] kmail forever indexing is back
could grow before we saw some breakage somewhere. :-)
Well, the relevant standard (RFC 5322 section 2.1.1) stipulates that an email header must be no more than 998 ASCII characters in length, so if something were going to break, I'd bet it would happen around there.
E. Liddell
Gene Heskett wrote:
Thanks again deloptes, I do believe that was it. Does the handbook mention this? Theres a fairly long list that I've not collated over the last 20 years. Most glaring is its inability to go get new mail in the background, which caused me to offload that to fetchmail-procmail and a chain of spam and viri catchers. All synchronized by inotifywait. I used to yell at Ingo K. over some of the more glaring ones till I figured our he was attempting to herd cats. And wasn't that good at it. ;-)
Glad to could have helped. I was going through the translations of TDEPIM and saw the string - connected this string to your issue, I thought this is it and located it in the config menu. I use KMail as primary mail client at home. I use it in Kontact. I have my old mail from university time in a maildir. Everything else is an IMAP. I think your process is complicated perhaps because of historic reasons and could be simplified. But this is my opinion. I like simple and clean solutions, because they are truly genius.
regards
On Sunday 15 December 2019 13:31:56 deloptes wrote:
Gene Heskett wrote:
Thanks again deloptes, I do believe that was it. Does the handbook mention this? Theres a fairly long list that I've not collated over the last 20 years. Most glaring is its inability to go get new mail in the background, which caused me to offload that to fetchmail-procmail and a chain of spam and viri catchers. All synchronized by inotifywait. I used to yell at Ingo K. over some of the more glaring ones till I figured our he was attempting to herd cats. And wasn't that good at it. ;-)
Glad to could have helped. I was going through the translations of TDEPIM and saw the string - connected this string to your issue, I thought this is it and located it in the config menu. I use KMail as primary mail client at home. I use it in Kontact. I have my old mail from university time in a maildir. Everything else is an IMAP. I think your process is complicated perhaps because of historic reasons and could be simplified. But this is my opinion. I like simple and clean solutions, because they are truly genius.
regards
while I hate it when the composer is frozen while typing a reply, but kmail thinks its time to access my isp's mail server, locking up the composer for sometimes over a minute. Being on SS, I have only a 10 megabit account, so big stuff takes a while. So I used fetchmail and friends to take that out of kmail's job list by doing all that in the background. And I think its creative too. kmail's composer freezes are a few milliseconds when it only pulls it from /var/mail. ;-)
Thank you deloptes.
Cheers, Gene Heskett
On Sunday 15 December 2019 12:55:45 Gene Heskett wrote:
On Sunday 15 December 2019 13:31:56 deloptes wrote:
Gene Heskett wrote:
Thanks again deloptes, I do believe that was it. Does the handbook mention this? Theres a fairly long list that I've not collated over the last 20 years. Most glaring is its inability to go get new mail in the background, which caused me to offload that to fetchmail-procmail and a chain of spam and viri catchers. All synchronized by inotifywait. I used to yell at Ingo K. over some of the more glaring ones till I figured our he was attempting to herd cats. And wasn't that good at it. ;-)
Glad to could have helped. I was going through the translations of TDEPIM and saw the string - connected this string to your issue, I thought this is it and located it in the config menu. I use KMail as primary mail client at home. I use it in Kontact. I have my old mail from university time in a maildir. Everything else is an IMAP. I think your process is complicated perhaps because of historic reasons and could be simplified. But this is my opinion. I like simple and clean solutions, because they are truly genius.
regards
while I hate it when the composer is frozen while typing a reply, but kmail thinks its time to access my isp's mail server, locking up the composer for sometimes over a minute. Being on SS, I have only a 10 megabit account, so big stuff takes a while. So I used fetchmail and friends to take that out of kmail's job list by doing all that in the background. And I think its creative too. kmail's composer freezes are a few milliseconds when it only pulls it from /var/mail. ;-)
Thank you deloptes.
Cheers, Gene Heskett
quoting:
Just found in the configuration options of KMail under (perhaps "Others") there is "Enable full text indexing". Is it checked for you by chance?
What happens if unchecked?
deloptes
For what it's worth ... I read the earlier email from deloptes (and I hope that a solution has been found for Gene's email): I *do* have that option checked; yet I have no problems like Gene describes.
If the issue is resolved, then I suppose this is a moot point; however, if the problem somehow returns, then this detail might be worth noting.
Bill
Gene Heskett wrote:
What happens if unchecked?
It stops instantly. THANK YOU VERY VERY MUCH, deloptes. I owe you a hand cooler or 2 but you'll have to come and get it cuz I've no clue where to send it. I am in North Central WV, USA.
Didn't have to time to reply in detail and still don't, but on that I'll let you know if I manage to do it in your life time.
regards
-
deloptes -
Dr. Nikolaus Klepp -
E. Liddell -
Gene Heskett -
Marvin Jones via trinity-users -
Michael -
William Morder via trinity-users