Re: Newsgroups with large number of posts hangs OE

I've figured out a partial workaround. I set the synchronization settings
in the large NGs I susbscribe to to "headers only" then use the "Sync All"
button which then proceeds to d/l all the headers of these large NGs. They
download much faster and I don't get the hangups when I access them later,
except for this one group that I subscribe to. I suppose that could
possibly be due to the server of that particular NG.....I dunno.

I also set the >Tools>Options>Read>News to only d/l the minimum (50) so when
I do go to the groups, OE doesn't try to d/l the sometimes hundreds more
posts that have gone onto the server since I started the sync operation.
It's kind of a hassle to do things this way, but since OE newsreader isn't
high on MS's priority list, it will have to do.

You guys have helped me a great deal and I want to thank everyone who gave
me suggestions and advice. While no one person gave me a definitive
solution, all the comments and advice helped point me in the direction I
needed to go to figure out a workaround.

drdug



"Steve Cochran" <scochran@xxxxxxxxxx> wrote in message
news:ukImvOARFHA.4028@xxxxxxxxxxxxxxxxxxxxxxx
> If you have a large NG such as what you are describing, you need to clean
> it up and compact the folder. The best way to do this is to right click
> on the folder name in the folder list. Then go to Properties | Local File
> and if you don't need the headers then click on the remove headers button,
> then click on the compact button. If you want the older headers, then
> just click on the compact button. Or use File | Folder | Compact while in
> that folder. That will reduce the size of the file to its minimum, given
> the number of headers and messages, and that should provide an increase in
> performance.
>
> You need to to this on a regular basis, to keep the file size as small as
> possible.
>
> steve
>
> "drdug" <nospam@xxxxxxxxxx> wrote in message
> news:e4BXfT1QFHA.2384@xxxxxxxxxxxxxxxxxxxxxxx
>> Thanks for your reply. I guess I wasn't clear enough in my original
>> post. I CAN d/l all the headers, but it stalls OE for up 30 minutes or
>> more. In fact the problem isn't on the initial download of headers...it
>> is on subsequent visits to the group after the initial download of a few
>> hundred thousand headers. OE loads the stored ones, which understandably
>> takes varying amounts of time to reach 100%.
>>
>> Then comes the new headers. This is what takes forever. Sometimes OE
>> gives a "(Not Responding)" in the title bar, other times it doesn't. And
>> it doesn't matter if there are only a few hundred headers to add or
>> several thousand. It's almost as if it is comparing every single stored
>> header on my computer with the server, and doing so VERY SLOWLY before
>> d/l any new headers.
>>
>> But I have noticed that if I go to Task Manager, it will say "not
>> responding" even when the title bar doesn't. Anyway, not only does OE
>> halt for a while, my whole system often slows to a crawl. Interestingly,
>> there isn't undo HDD activity, which I would expect with an entire system
>> slowdown like that. Nor does Task Manager show any one process taking up
>> the CPU resources.
>>
>> As far as the diagnostic suggestions, I fear you are casting pearls
>> before swine, as I haven't attained that level of geekdom yet, and don't
>> know what to make of the netstat results. I did try it though, hoping it
>> would tell me something I could understand.
>>
>>
>>
>>
>> "Robert Aldwinckle" <robald@xxxxxxxxxxxxx> wrote in message
>> news:OL15wcXQFHA.3196@xxxxxxxxxxxxxxxxxxxxxxx
>>> "drdug" <nospam@xxxxxxxxxx> wrote in message
>>> news:eEaLaJTQFHA.164@xxxxxxxxxxxxxxxxxxxx
>>> ...
>>>> if you d/l only part of the headers, you may be
>>>> missing something you want to d/l.
>>> ...
>>>
>>> The subject of this thread is a complaint about being unable
>>> to download *all* headers. I have shown you that you could download
>>> *all* headers provided you are willing to do it in pieces.
>>>
>>> BTW have you tried diagnosing your "not responding" symptom?
>>> E.g. try using netstat -ps tcp 5 to see if anything is actually
>>> still
>>> going on underneath. As long as something is still happening
>>> you can ignore the symptom and expect that eventually a complete
>>> response to your request will be given.
>>>
>>> However, depending on how your server packages such a response,
>>> I wouldn't be surprised if the server is at fault and not OE.
>>> For that particular response the troubleshooting log will be inadequate
>>> to help you understand the symptom. For it you would need to invoke
>>> a TCP packet trace to capture the full NNTP protocol.
>>>
>>>
>>> Robert
>>> ---
>>>
>>>
>>
>>
>


.