pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pan-users] Re: [Pan 0.133-Windows] Drops server


From: Duncan
Subject: [Pan-users] Re: [Pan 0.133-Windows] Drops server
Date: Fri, 26 Sep 2008 14:03:37 +0000 (UTC)
User-agent: Pan/0.133 (House of Butterflies)

Kurt Schilling <address@hidden>
posted address@hidden, excerpted below, on  Fri, 26 Sep
2008 07:44:05 -0400:

> I use 0.133 on both a Windows box and my Linux box. I currently
> subscribe to three server feeds. Two are private servers, the third is
> Motzarella. I have noted that as I switch between subscribed newsgroups
> on the different servers that the connexion to Motz gets dropped. The
> list of subscribe groups is alphbetical, so by the time I get to
> news.software.readers Pan indicates that No Tasks remain and no new
> headers are downloaded. I can exit the program and re-establish a
> connexion to Motz, and Pan will then fetch new headers. Any
> sugggestions?

Pan normally does a keep-alive, sending what is effectively an "I'm still 
here, don't disconnect" request to each server every few minutes.  
However, some servers still timeout after some server-configured time 
period if that's all they are getting.

Here, my ISP's (outsourced) news service still disconnects after a 
certain time -- and the pan log will show an error and apparently quit 
sending the keep-alives after that.  However, the server /should/ 
reconnect fairly quickly if you actually start doing something on it.  I 
know it /normally/ does here, tho there's an occasional temporary hiccup 
and I'll say compose a reply, have it timeout in the mean time, and won't 
get an immediate send when I try to send.  However, if I let it sit, 
still trying to send, a couple minutes, it'll almost always eventually 
connect and the message will be sent.  If it doesn't, there's worse 
server-side issues.

You might try going offline (in pan) temporarily, hitting the refresh 
button so it queues the tasks, then going online.

Other than that I don't know what to say, except to note that you can 
check what the OS thinks exist in terms of connections using the netstat 
command.  It should work on both MS and Linux, tho parameters may vary.  
If the OS still sees a normal connection, that could be a problem.  If it 
sees one that's still stuck in time-wait, that's a different problem (the 
connection got half-closed but the last bit of the close handshake 
sequence disappeared somewhere).

> One other quick question: is there a way of stripping out the added
> carriage returns above the sig delimiter? They add extra space to a post
> or follow up that have to be manually deleted.

I don't find it too bad here, probably because it's just habit to delete 
the extras, now, but you're right, there's a few extra CRs in there and 
it is (mildly) annoying.  I'm not sure why there's so many, except that I 
think Charles may be putting them there to help to encourage proper quote/
reply form, instead of top posting.  If the cursor and an obvious blank 
is at the bottom...

The other possibility is that it's to do with the interplay between the 
profile and the sig handling.  If you have several posting profiles (with 
different sigs) and try switching them, you should notice that if you've 
deleted the extra lines, they come back when you switch profiles.

You could play around with the various sig type options.  It has been 
awhile since I tried that and I only tried the two text options (FWIW I 
use text file, now), but that might change the number of blank lines 
inserted.

If I was a C++ coder, that'd have probably "itched" long enough by now to 
cause me to scratch it, looking into creating a patch to fix it, but I'm 
not and obviously it's not itching bad enough for those that are to have 
bugged and filed a patch for it yet, so...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman





reply via email to

[Prev in Thread] Current Thread [Next in Thread]