After installing version 1.9.9.5 the download won’t run
It stands completely still
I went back to version 1.9.9.3 and the download starts running ,on full speed
What can be the problem with version 1.9.9.5 ??
Greatings
PcKiller
v1.9.9.5
Very strange
UE never had a problem with windows firewall
I shut the firewall down ,and UE was running again on full speed
Then I activate fire wall ,and UE keeps on running of full speed
Shut down UE , and start it again, and keeps on running on full speed
Very strange ,but problem seems to be solved
Thanks for the support
Have a nice evening
PcKiller
UE never had a problem with windows firewall
I shut the firewall down ,and UE was running again on full speed
Then I activate fire wall ,and UE keeps on running of full speed
Shut down UE , and start it again, and keeps on running on full speed
Very strange ,but problem seems to be solved
Thanks for the support
Have a nice evening
PcKiller
i had that same problem,
i am just not so lucky as to find an earlier version.
this is not a firewall issue.
my firewall allows usenet 1.9.9.5. to connect.
i have windows life one care firewall.
as soon as i open that version of usenet my whole pc stops functioning almost.
everything goes extremely slow till i close usenet. after that everything rus fine again.
maybe someone can tell me where to find an older version so i can keep downloading?
i am just not so lucky as to find an earlier version.
this is not a firewall issue.
my firewall allows usenet 1.9.9.5. to connect.
i have windows life one care firewall.
as soon as i open that version of usenet my whole pc stops functioning almost.
everything goes extremely slow till i close usenet. after that everything rus fine again.
maybe someone can tell me where to find an older version so i can keep downloading?
does anyone have the same problem with v1.9.9.7?
i was reported an issue which we have traced to a racing condition so when there are preexisting article tasks in the queue (it couldn't happen when initial queue is empty) they could start a bit earlier than their link to sending messages initialized.
i think more likely it could happen on multi-core processors.
with the old shutdown code it could give almost innocuous "Send message failed" error in the error pane (not always since it is racing).
with the new shutdown code if the condition kicked in it locked the network thread. every locked network thread would keep one core busy, so you see processor usage, but the program would remain unlocked since it is not the main thread. shutdown was still fast since closing the program would immediately unlock those threads, not even emergency shutdown.
the condition could easily remain unnoticed, but i used a non-needed local variable which "remembered" the immediate value of the window handle so if racing condition kicked in it was made artificially persistent, if i used static variable instead, it would work just waiting until the window becomes available instead of correct start sequence and noone would pay attention.
still it was important to make SSL working with ungraceful servers and also to make the shutdown code independent of non-UE locks, just everything has its price.
i was reported an issue which we have traced to a racing condition so when there are preexisting article tasks in the queue (it couldn't happen when initial queue is empty) they could start a bit earlier than their link to sending messages initialized.
i think more likely it could happen on multi-core processors.
with the old shutdown code it could give almost innocuous "Send message failed" error in the error pane (not always since it is racing).
with the new shutdown code if the condition kicked in it locked the network thread. every locked network thread would keep one core busy, so you see processor usage, but the program would remain unlocked since it is not the main thread. shutdown was still fast since closing the program would immediately unlock those threads, not even emergency shutdown.
the condition could easily remain unnoticed, but i used a non-needed local variable which "remembered" the immediate value of the window handle so if racing condition kicked in it was made artificially persistent, if i used static variable instead, it would work just waiting until the window becomes available instead of correct start sequence and noone would pay attention.
still it was important to make SSL working with ungraceful servers and also to make the shutdown code independent of non-UE locks, just everything has its price.
it was a mix of firewall access and the race condition questions.
as to the firewall all remains the same, so if firewall blocks access because of changed executable one needs to delete/readd UE in the firewall definitions (it appears microsoft live firewall has such an issue, i was told it also was needed for the latest version).
as to UE i can fix any problem as long as it is reproducible, but the reliability now is at the highest peak.
as to the firewall all remains the same, so if firewall blocks access because of changed executable one needs to delete/readd UE in the firewall definitions (it appears microsoft live firewall has such an issue, i was told it also was needed for the latest version).
as to UE i can fix any problem as long as it is reproducible, but the reliability now is at the highest peak.