A.D. Fundum
2015-08-17 19:05:39 UTC
Discussion:
(too old to reply)
Dave Yeo
2015-08-18 01:22:11 UTC
Did that still work in 2.28a1?
Dave
Dave
Dave Yeo
2015-08-18 04:34:20 UTC
Of course not, I found the problem, not sure how to fix so filed
https://github.com/bitwiseworks/mozilla-os2/issues/133
Thanks for the report,
Dave
https://github.com/bitwiseworks/mozilla-os2/issues/133
Thanks for the report,
Dave
A.D. Fundum
2015-08-18 17:33:20 UTC
Confirmed. I recently noticed it, after downloading a new add-on.
Thank you. Now I won't even try to write an utility to use the list of
downloaded file to add the .subject EA to downloaded files. I haven't
really bookmarked that RUP/YRM ZIP file site, but instead I've used
the recorded EA.
BTW, so far I haven't experienced a crash while downloading files
anymore, and all downloaded files at Hobbes were marked as visited
links (HTML's vlink-color).
So far the only new [italic]problem[/italic] since 2.28 is the initial
CPU load of ~100%, during about 10-20 seconds (YMMV) after about:blank
is displayed.
Oh, and using the parameter "-compose mailto:[mailto:]" is dangerous.
If SM2.28a1 isn't running yet, then it may crash before the email
(with two attachments) is actually sent. In other words: you don't
know for sure, because there's no confirmation message, and it will
take (too) long. Don't trust it, unless SM is already running.
--
Thank you. Now I won't even try to write an utility to use the list of
downloaded file to add the .subject EA to downloaded files. I haven't
really bookmarked that RUP/YRM ZIP file site, but instead I've used
the recorded EA.
BTW, so far I haven't experienced a crash while downloading files
anymore, and all downloaded files at Hobbes were marked as visited
links (HTML's vlink-color).
So far the only new [italic]problem[/italic] since 2.28 is the initial
CPU load of ~100%, during about 10-20 seconds (YMMV) after about:blank
is displayed.
Oh, and using the parameter "-compose mailto:[mailto:]" is dangerous.
If SM2.28a1 isn't running yet, then it may crash before the email
(with two attachments) is actually sent. In other words: you don't
know for sure, because there's no confirmation message, and it will
take (too) long. Don't trust it, unless SM is already running.
--
Dave Yeo
2015-08-19 02:55:26 UTC
Post by A.D. Fundum
Confirmed. I recently noticed it, after downloading a new add-on.
Thank you. Now I won't even try to write an utility to use the list of
downloaded file to add the .subject EA to downloaded files. I haven't
really bookmarked that RUP/YRM ZIP file site, but instead I've used
the recorded EA.
I often just use history.Confirmed. I recently noticed it, after downloading a new add-on.
Thank you. Now I won't even try to write an utility to use the list of
downloaded file to add the .subject EA to downloaded files. I haven't
really bookmarked that RUP/YRM ZIP file site, but instead I've used
the recorded EA.
At one point, before Mozilla gained the ability, someone had a script to
add the URLs to the EAs. Probably could be reimplemented by reading the
downloads.sqlite database.
Post by A.D. Fundum
BTW, so far I haven't experienced a crash while downloading files
anymore, and all downloaded files at Hobbes were marked as visited
links (HTML's vlink-color).
Yes, the crashes seem to be gone. I never had a problem with visitedBTW, so far I haven't experienced a crash while downloading files
anymore, and all downloaded files at Hobbes were marked as visited
links (HTML's vlink-color).
links changing colour until I upgraded to 2.28, then an add-on screwed
up my places.sqlite and I finally had to delete it to get history
working properly again as I accidentally overwrote my backup.
Post by A.D. Fundum
So far the only new [italic]problem[/italic] since 2.28 is the initial
CPU load of ~100%, during about 10-20 seconds (YMMV) after about:blank
is displayed.
I haven't noticed that, though I usually have enough tabs open that allSo far the only new [italic]problem[/italic] since 2.28 is the initial
CPU load of ~100%, during about 10-20 seconds (YMMV) after about:blank
is displayed.
versions spike the CPU while repopulating.
With 2.28, session restore is partially broken so shutdown is really
quick but the latest pages aren't always saved and SM forgets where in a
page I was. The cache also seems to be partially broken. Possibly the
reason that 2.28 was never actually released on tier 1 platforms.
Post by A.D. Fundum
Oh, and using the parameter "-compose mailto:[mailto:]" is dangerous.
If SM2.28a1 isn't running yet, then it may crash before the email
(with two attachments) is actually sent. In other words: you don't
know for sure, because there's no confirmation message, and it will
take (too) long. Don't trust it, unless SM is already running.
Weird race condition? I never use it like that so haven't noticedOh, and using the parameter "-compose mailto:[mailto:]" is dangerous.
If SM2.28a1 isn't running yet, then it may crash before the email
(with two attachments) is actually sent. In other words: you don't
know for sure, because there's no confirmation message, and it will
take (too) long. Don't trust it, unless SM is already running.
Dave
A.D. Fundum
2015-08-19 12:58:25 UTC
Post by Dave Yeo
open that all versions spike the CPU while repopulating.
Loading Image...Post by A.D. Fundum
So far the only new [italic]problem[/italic] since 2.28 is the
initial CPU load of ~100%, during about 10-20 seconds
(YMMV) after about:blank is displayed.
I haven't noticed that, though I usually have enough tabsSo far the only new [italic]problem[/italic] since 2.28 is the
initial CPU load of ~100%, during about 10-20 seconds
(YMMV) after about:blank is displayed.
open that all versions spike the CPU while repopulating.
(0.5 KiB)The red spike to the left belongs to FF 31.8.0b5 (closed again, but
started to be able to see the difference, and it's about the same red
spike as SM's red spikes to the left of the "2" of "2.8%".
To the right you can see the (mainly green) SM-specific initial CPU
load of ~100% (2.7 GHz Pentium 4, 2 GiB RAM). My default homepage is
the first radiobutton, "Blank page".
Possibly. I've used this WPS parameter twice, and it crashed twice. It
looks like the actual sending it slow, as if there's a sever-related
problem. You'll see all progress updates, expect the last one
("Message successfully sent"). SM crashes, but you'll find the email
in "Sent items". I don't know for sure if such an email was delivered.
The expected result is that SM should exit, but cleanly.
So far I never saw this when SM (browser window or email windows) was
running after sending the email, i.e. typical usage. It's not that
important. The slowlyness is an indication that there's a problem, and
AFAIK an installer doesn't create such a start-mailto-exit-object.
--
A.D. Fundum
2015-08-19 13:09:40 UTC
My default homepage is the first radiobutton, "Blank page".
And you can try to start typing an URL, but that will look like tryingto use Windows while it's desperately torturing your harddisk.
Apparently the browser window is ready and working, like FF would be
reaqdy-to-use, but SM is still busy for a while.
Actual incoming emails shouldn't play a role. I haven't received many
emails nor large emails recently, and I can always notice such an
initial CPU load since SM2.28..
--
Dave Yeo
2015-08-19 23:50:18 UTC
Post by A.D. Fundum
The red spike to the left belongs to FF 31.8.0b5 (closed again, but
started to be able to see the difference, and it's about the same red
spike as SM's red spikes to the left of the "2" of "2.8%".
To the right you can see the (mainly green) SM-specific initial CPU
load of ~100% (2.7 GHz Pentium 4, 2 GiB RAM). My default homepage is
the first radiobutton, "Blank page".
Just tested with a fairly new profiles and the home page set toPost by Dave Yeo
open that all versions spike the CPU while repopulating.
http://home.uni-one.nl/m1/cpuload.png (0.5 KiB)Post by A.D. Fundum
So far the only new [italic]problem[/italic] since 2.28 is the
initial CPU load of ~100%, during about 10-20 seconds
(YMMV) after about:blank is displayed.
I haven't noticed that, though I usually have enough tabsSo far the only new [italic]problem[/italic] since 2.28 is the
initial CPU load of ~100%, during about 10-20 seconds
(YMMV) after about:blank is displayed.
open that all versions spike the CPU while repopulating.
The red spike to the left belongs to FF 31.8.0b5 (closed again, but
started to be able to see the difference, and it's about the same red
spike as SM's red spikes to the left of the "2" of "2.8%".
To the right you can see the (mainly green) SM-specific initial CPU
load of ~100% (2.7 GHz Pentium 4, 2 GiB RAM). My default homepage is
the first radiobutton, "Blank page".
about:blank,
Loading Image...
(2.5kb, SM wants to download it). On the right is SM startup, just to
the left is Firefox startup, first small spike is the profile manager in
both cases. Not much different here and SM is responsive by the time I
click on the URL bar. CPU is 1st gen C2D at 2.6Ghz, 2GB ram.
Perhaps test with a new profile or in safe-mode.
Post by A.D. Fundum
Possibly. I've used this WPS parameter twice, and it crashed twice. It
looks like the actual sending it slow, as if there's a sever-related
problem. You'll see all progress updates, expect the last one
("Message successfully sent"). SM crashes, but you'll find the email
in "Sent items". I don't know for sure if such an email was delivered.
The expected result is that SM should exit, but cleanly.
So far I never saw this when SM (browser window or email windows) was
running after sending the email, i.e. typical usage. It's not that
important. The slowlyness is an indication that there's a problem, and
AFAIK an installer doesn't create such a start-mailto-exit-object.
How exactly do you use the "-compose mailto:[mailto:]"? I'd like to testPossibly. I've used this WPS parameter twice, and it crashed twice. It
looks like the actual sending it slow, as if there's a sever-related
problem. You'll see all progress updates, expect the last one
("Message successfully sent"). SM crashes, but you'll find the email
in "Sent items". I don't know for sure if such an email was delivered.
The expected result is that SM should exit, but cleanly.
So far I never saw this when SM (browser window or email windows) was
running after sending the email, i.e. typical usage. It's not that
important. The slowlyness is an indication that there's a problem, and
AFAIK an installer doesn't create such a start-mailto-exit-object.
but don't have much time right now.
Dave
Dave Yeo
2015-08-20 01:11:14 UTC
Post by Dave Yeo
about:blank,
https://bitbucket.org/dryeo/dry-comm-esr31/downloads/cpu_load.png
(2.5kb, SM wants to download it). On the right is SM startup, just to
the left is Firefox startup, first small spike is the profile manager in
both cases. Not much different here and SM is responsive by the time I
click on the URL bar. CPU is 1st gen C2D at 2.6Ghz, 2GB ram.
Perhaps test with a new profile or in safe-mode.
but don't have much time right now.
Dave
Weird, posted this, tried to load and server replied that it was expiredPost by A.D. Fundum
The red spike to the left belongs to FF 31.8.0b5 (closed again, but
started to be able to see the difference, and it's about the same red
spike as SM's red spikes to the left of the "2" of "2.8%".
To the right you can see the (mainly green) SM-specific initial CPU
load of ~100% (2.7 GHz Pentium 4, 2 GiB RAM). My default homepage is
the first radiobutton, "Blank page".
Just tested with a fairly new profiles and the home page set toPost by Dave Yeo
open that all versions spike the CPU while repopulating.
http://home.uni-one.nl/m1/cpuload.png (0.5 KiB)Post by A.D. Fundum
So far the only new [italic]problem[/italic] since 2.28 is the
initial CPU load of ~100%, during about 10-20 seconds
(YMMV) after about:blank is displayed.
I haven't noticed that, though I usually have enough tabsSo far the only new [italic]problem[/italic] since 2.28 is the
initial CPU load of ~100%, during about 10-20 seconds
(YMMV) after about:blank is displayed.
open that all versions spike the CPU while repopulating.
The red spike to the left belongs to FF 31.8.0b5 (closed again, but
started to be able to see the difference, and it's about the same red
spike as SM's red spikes to the left of the "2" of "2.8%".
To the right you can see the (mainly green) SM-specific initial CPU
load of ~100% (2.7 GHz Pentium 4, 2 GiB RAM). My default homepage is
the first radiobutton, "Blank page".
about:blank,
https://bitbucket.org/dryeo/dry-comm-esr31/downloads/cpu_load.png
(2.5kb, SM wants to download it). On the right is SM startup, just to
the left is Firefox startup, first small spike is the profile manager in
both cases. Not much different here and SM is responsive by the time I
click on the URL bar. CPU is 1st gen C2D at 2.6Ghz, 2GB ram.
Perhaps test with a new profile or in safe-mode.
Post by A.D. Fundum
Possibly. I've used this WPS parameter twice, and it crashed twice. It
looks like the actual sending it slow, as if there's a sever-related
problem. You'll see all progress updates, expect the last one
("Message successfully sent"). SM crashes, but you'll find the email
in "Sent items". I don't know for sure if such an email was delivered.
The expected result is that SM should exit, but cleanly.
So far I never saw this when SM (browser window or email windows) was
running after sending the email, i.e. typical usage. It's not that
important. The slowlyness is an indication that there's a problem, and
AFAIK an installer doesn't create such a start-mailto-exit-object.
How exactly do you use the "-compose mailto:[mailto:]"? I'd like to testPossibly. I've used this WPS parameter twice, and it crashed twice. It
looks like the actual sending it slow, as if there's a sever-related
problem. You'll see all progress updates, expect the last one
("Message successfully sent"). SM crashes, but you'll find the email
in "Sent items". I don't know for sure if such an email was delivered.
The expected result is that SM should exit, but cleanly.
So far I never saw this when SM (browser window or email windows) was
running after sending the email, i.e. typical usage. It's not that
important. The slowlyness is an indication that there's a problem, and
AFAIK an installer doesn't create such a start-mailto-exit-object.
but don't have much time right now.
Dave
and won't let me repost. Yet here it is on a different server. Lets see
if this works
Dave
Dave Yeo
2015-08-20 01:12:32 UTC
Post by Dave Yeo
Weird, posted this, tried to load and server replied that it was expired
and won't let me repost. Yet here it is on a different server. Lets see
if this works
Yes, shows up on original server (astraweb)Weird, posted this, tried to load and server replied that it was expired
and won't let me repost. Yet here it is on a different server. Lets see
if this works
Dave
A.D. Fundum
2015-08-20 17:10:05 UTC
Post by Dave Yeo
https://bitbucket.org/dryeo/dry-comm-esr31/downloads/cpu_load.png
Perhaps test with a new profile or in safe-mode.
Allright. My first test will be the -mail parameter (as soon as I'mhttps://bitbucket.org/dryeo/dry-comm-esr31/downloads/cpu_load.png
Perhaps test with a new profile or in safe-mode.
willing to download and see all incoming emails), because there are
~3,000 unread, uncompressed messages in the Inbox of my profile.
Perhaps the browser "thread" is competing with a bunch of emails.
The CPU load of 100% is new since SM2.28. The number nor size of
possibly incoming emails is worth mentioning. I'll always see such a
CPU load.
1. Make sure that SM isn't running anymore, e.g. after a WPS reset.
2. Use it as the parameter of a SEAMPONKEY.EXE WPS object
3. Start this object
4. Use the PM entry field to enter/paste an email address
5. Type an email, perhaps attach a few documents (50-100 KB'ish)
6. Send
7. Try to see the status updates and confirmation messages
8. SM should exit normally
9. Start SM again.
10. You should find your email in Sent items
11. Did the email address actually receive the email?
6: this may take a long time, as if the (SMTP) server is down or
extremely slow.
7: you may miss the last one, the final confirmation.
10: expected result, always: yes.
11: this is not reliable, AFAICT, without having been able to verify
this.
--
Dave Yeo
2015-08-21 04:01:26 UTC
Post by A.D. Fundum
willing to download and see all incoming emails), because there are
~3,000 unread, uncompressed messages in the Inbox of my profile.
Perhaps the browser "thread" is competing with a bunch of emails.
If you mean your local SM inbox, this may have something to do with yourPost by Dave Yeo
https://bitbucket.org/dryeo/dry-comm-esr31/downloads/cpu_load.png
Perhaps test with a new profile or in safe-mode.
Allright. My first test will be the -mail parameter (as soon as I'mhttps://bitbucket.org/dryeo/dry-comm-esr31/downloads/cpu_load.png
Perhaps test with a new profile or in safe-mode.
willing to download and see all incoming emails), because there are
~3,000 unread, uncompressed messages in the Inbox of my profile.
Perhaps the browser "thread" is competing with a bunch of emails.
100% CPU load as well as your -compose problem.
Post by A.D. Fundum
The CPU load of 100% is new since SM2.28. The number nor size of
possibly incoming emails is worth mentioning. I'll always see such a
CPU load.
1. Make sure that SM isn't running anymore, e.g. after a WPS reset.
2. Use it as the parameter of a SEAMPONKEY.EXE WPS object
3. Start this object
4. Use the PM entry field to enter/paste an email address
5. Type an email, perhaps attach a few documents (50-100 KB'ish)
6. Send
7. Try to see the status updates and confirmation messages
8. SM should exit normally
9. Start SM again.
10. You should find your email in Sent items
11. Did the email address actually receive the email?
6: this may take a long time, as if the (SMTP) server is down or
extremely slow.
7: you may miss the last one, the final confirmation.
10: expected result, always: yes.
11: this is not reliable, AFAICT, without having been able to verify
this.
I tested a few messages and it worked as expected.The CPU load of 100% is new since SM2.28. The number nor size of
possibly incoming emails is worth mentioning. I'll always see such a
CPU load.
1. Make sure that SM isn't running anymore, e.g. after a WPS reset.
2. Use it as the parameter of a SEAMPONKEY.EXE WPS object
3. Start this object
4. Use the PM entry field to enter/paste an email address
5. Type an email, perhaps attach a few documents (50-100 KB'ish)
6. Send
7. Try to see the status updates and confirmation messages
8. SM should exit normally
9. Start SM again.
10. You should find your email in Sent items
11. Did the email address actually receive the email?
6: this may take a long time, as if the (SMTP) server is down or
extremely slow.
7: you may miss the last one, the final confirmation.
10: expected result, always: yes.
11: this is not reliable, AFAICT, without having been able to verify
this.
I usually use Thunderbird for email so have mostly newsgroups in SM.
Thunderbird is slow, often lagging with the hourglass pointer (I have a
lot of messages) but low CPU load and no disk activity.
Dave
Dave
A.D. Fundum
2015-08-21 21:37:48 UTC
Post by Dave Yeo
If you mean your local SM inbox, this may have something
to do with your 100% CPU load as well as your -compose
problem.
Allright, that's quite likely. Any initial page seems to be loadedIf you mean your local SM inbox, this may have something
to do with your 100% CPU load as well as your -compose
problem.
fast. In safe-mode it's fast. The size of the file Inbox is 224 MB,
uncompressed. With the -mail parameter I'm seeing the same 100% CPU
load.
Hmm... The size of the file Drafts is also 224 MB. I was expecting an
"empty" file. Is there a way to rebuild the files, to exclude
corrupted files? Drafts.msf is a small, for example. I don't have a
reason to assume corrupted files, by the way.
16-08-15 17:48 224.146.471 0 a--- Drafts
21-08-15 23:15 3.623 124 a--- Drafts.msf
21-08-15 17:28 224.330.553 0 a--- Inbox
21-08-15 23:15 2.119.259 124 a--- Inbox.msf
7-12-14 19:19 27 0 a--- msgFilterRules.dat
19-08-15 19:01 43.487.435 0 a--- Sent
21-08-15 23:15 2.682 124 a--- Sent.msf
18-08-15 4:45 77.725.017 0 a--- Trash
21-08-15 23:15 5.692 124 a--- Trash.msf
5-06-14 20:07 0 0 a--- Unsent Messages
21-08-15 23:15 1.582 124 a--- Unsent Messages.msf
Disk size (archive, executables) will be a problem compared to a
number of seconds, but is it possible to append "exported" SM emails
to a TB archive? In other words: use SM daily, but sometimes move a
few emails to the TB archive, and use TB to manage the archive.
As such using TB is an option indeed.
--
A.D. Fundum
2015-08-21 22:28:50 UTC
rebuild the files, to exclude corrupted files?
http://kb.mozillazine.org/Compacting_foldersThe translation is confusing. It looks like "compacting" was
translated as "compressing", as if each time 224 MB has to be ZIPped
and UNZIPped.
--
A.D. Fundum
2015-08-21 23:40:24 UTC
FTR: the CPU load stil is 100% for about the same while. Really
deleting old, "hidden" messages by compacting didn't automagically
solve that.
22-08-15 0:43 0 0 a--- Drafts
22-08-15 0:43 1.515 124 a--- Drafts.msf
22-08-15 0:44 154.320.680 0 a--- Inbox
22-08-15 0:47 1.697.746 124 a--- Inbox.msf
7-12-14 19:19 27 0 a--- msgFilterRules.dat
22-08-15 0:45 0 0 a--- Sent
22-08-15 0:45 1.532 124 a--- Sent.msf
22-08-15 0:45 0 0 a--- Trash
22-08-15 0:47 1.547 124 a--- Trash.msf
5-06-14 20:07 0 0 a--- Unsent Messages
22-08-15 0:29 1.978 124 a--- Unsent Messages.msf
--
deleting old, "hidden" messages by compacting didn't automagically
solve that.
22-08-15 0:43 0 0 a--- Drafts
22-08-15 0:43 1.515 124 a--- Drafts.msf
22-08-15 0:44 154.320.680 0 a--- Inbox
22-08-15 0:47 1.697.746 124 a--- Inbox.msf
7-12-14 19:19 27 0 a--- msgFilterRules.dat
22-08-15 0:45 0 0 a--- Sent
22-08-15 0:45 1.532 124 a--- Sent.msf
22-08-15 0:45 0 0 a--- Trash
22-08-15 0:47 1.547 124 a--- Trash.msf
5-06-14 20:07 0 0 a--- Unsent Messages
22-08-15 0:29 1.978 124 a--- Unsent Messages.msf
--
Dave Yeo
2015-08-22 00:06:34 UTC
Post by A.D. Fundum
The translation is confusing. It looks like "compacting" was
translated as "compressing", as if each time 224 MB has to be ZIPped
and UNZIPped.
The mbox file format gets holes in it, eg when deleting a message orrebuild the files, to exclude corrupted files?
http://kb.mozillazine.org/Compacting_foldersThe translation is confusing. It looks like "compacting" was
translated as "compressing", as if each time 224 MB has to be ZIPped
and UNZIPped.
when a filter moves it to a different folder, it is still there.
Compacting moves all the good emails to a new file, then deletes the old
file and replaces it with the new file. You should do it regularly for
inbox and any other folder/file that mails come and go in such as drafts.
Dave
Dave Yeo
2015-08-22 00:02:39 UTC
Post by A.D. Fundum
Disk size (archive, executables) will be a problem compared to a
number of seconds, but is it possible to append "exported" SM emails
to a TB archive? In other words: use SM daily, but sometimes move a
few emails to the TB archive, and use TB to manage the archive.
As such using TB is an option indeed.
Should be able to create an empty folder in TB, close TB and copy yourDisk size (archive, executables) will be a problem compared to a
number of seconds, but is it possible to append "exported" SM emails
to a TB archive? In other words: use SM daily, but sometimes move a
few emails to the TB archive, and use TB to manage the archive.
As such using TB is an option indeed.
mbox over. By mbox I mean the 224MB file, drafts or inbox. Then restart
TB and it will build a msf file for that folder. Should compact the mbox
first and of course have a backup as it is untested.
Dave
A.D. Fundum
2015-08-22 00:22:31 UTC
Understood and thanks, I've used that to merge Netscape folders.
With the -mail parameter it looks like the mail server's processing
speed is slow (since 2.28), albeit it's possible that the status
updates are also suffering from the CPU load. Nevertheless I can read
about all updates, and the CPU loads drops immediately after the
authentication. So it may be a generic problem, related to a specific
situation.
With -compose the server appears to be slow too during the _initial_
connection with the mail server.
I won't contact the (small) ISP, because they want to stop offering
email services and I don't want to encourage nor hurry that decision.
--
With the -mail parameter it looks like the mail server's processing
speed is slow (since 2.28), albeit it's possible that the status
updates are also suffering from the CPU load. Nevertheless I can read
about all updates, and the CPU loads drops immediately after the
authentication. So it may be a generic problem, related to a specific
situation.
With -compose the server appears to be slow too during the _initial_
connection with the mail server.
I won't contact the (small) ISP, because they want to stop offering
email services and I don't want to encourage nor hurry that decision.
--