Re: [Pan-users] New Windows installer

[Alan Taylor]

>>
>> The fix/solution is to delete the existing C:/users/USERid/.pan2
>> directory before trying to install, because (I guess) the uninstaller
>> doesn't delete it and its presence somehow messes up the new install.
>> After deleting that directory Pan will install and run.
>
> It would be interesting to bisect it down to a specific file, and then,
> assuming it's a settings file, down to a specific setting in the file.
> But that's a lot of work some people won't have the time/motivation to
> do.  But speaking from experience, knowing exactly what setting triggered
> the problem feels pretty good, as it helps put you in control of the
> problem, not the other way around. =:^)

I know what you mean and I'll give bisecting the .pan2 directory a try.

>
>> I think I had to reboot before my ISP would recognize Pan, otherwise I
>> got a "authentication required" error.  Authentication is *not*
>> required on my fibre-to-the-home setup.
>
> One of the problems Linux users have been reporting is sort of the
> opposite of that, tho I don't believe the problem was an authentication
> error.  Pan would work the first time after its directory was cleaned out
> and a new configuration created, but shutting it down and restarting with
> even the new configuration would result in problems, again.  Pan would
> only work when started fresh, and couldn't work with an existing config,
> even if it had just rebuilt it, at all.
>
> So it's nice to see at least you aren't seeing that problem, even if a
> reboot is needed to get pan working properly.
>
> But that's one reason why bisecting the problem with the old config may
> be useful, because it may yield further hints on what's causing pan to
> dislike any config at all, on the Linux side.

I think rebooting is not a big deal myself.  As I recall, I had been
running Grabit before installing the newest Pan so, even though Grabit
was paused there may have been something interfering with Pan.
Actually Grabit has its own problem - after running for some time it
starts to report "authentication required" (it isn't).  The problem
may go away eventually, or I can restart Grabit and it works.  No
cache problem I can find.  In trying the bisect above I will find out
if installing Pan really needs a reboot in absence of any Grabit
activity.  With Grabit I thought it might be my ISP because this
didn't happen some time ago..


>> Then pan runs fine, until the article-cache fills up.  This is a problem
>> I have had with previous versions, I don't recall how many-seems like
>> all of them for the past 5(?) or more years.
>>
SNIP
>>

> How do you use pan to download those binaries?  There are two
> possibilities, one of which should work fine with the default 10 MiB
> cache size, one of which will require a far larger cache size; I've
> worked with 12 GiB caches here.  So see which of the following matches
> your download method and adjust either your method or your cache size,
> accordingly.
>
> In the one case, which to my knowledge works fine with even the tiny
> default 10 MiB cache, you select messages before downloading anything,
> and tell pan to download and save the attachments directly, using the
> "save" functions directly, before anything is cached.  This works, or has
> in the past, anyway, because pan works on only a few messages at a time
> and knows what messages it has already saved the attachments from and can
> delete to keep the cache at its configured size.

This *is* how I use Pan, but 10 MB or 100 MB doesn't cover it.  I am
now running 1000 MB article-cache and the size is staying at 799 MB
even while downloads continue successfully.  So I may have worked
around my problem with the cache size although, as you say, it should
work at a much smaller cache.

>
> That's apparently how pan's long-time head dev, Charles Kerr, worked, and
> pan was designed around that download method, so it has worked pretty
> well.   If that's how you're using pan and you're still having cache
> expiry problems, then you may well have found a new bug, or at least I've
> not seen it discussed here.
>
>
> The other alternative, which I tend to prefer, and which I'd guess most
> folks who started on USENET with MSOE (as I did, back in the MS Windows
> 95 era, with IE/OE4, before it was integrated into MS Windows 98) or
> similar tools may find more intuitive, is to first download messages of
> interest to cache (using cache article instead of save), then once
> they're in local cache, browse thru them, saving off attachments or
> deleting them as desired.
>
> Back in 2002 or so when I first started using pan, I couldn't figure out
> why it was deleting most parts of most messages before I'd even read
> them.  It turned out that it was because I was using the second method,
> download to cache and then go thru the messages again when they're local,
> while pan's default cache size was designed with the first method in mind.
>
> If this is your problem as it was mine, there are two possible fixes.
> One is to change the way you work to fit the way pan was designed to
> work.  Don't download to cache (the second method) any more.  Instead,
> save attachments off directly (the first method), so they're saved as
> they download and pan's tiny 10 MiB default cache works fine.

I have tried this method and seen this problem myself with just-recent
versions of Pan, so now I use the method above and delete unwanted
downloads on my disk (saved using Read Article) rather from "Cache
Article".

Time to restart Pan is not a problem for me I guess because I have Pan
set to empty the cache at shutdown.  Thus on start-up, the cache is
always empty.

Engineeral.