Re: [Pan-users] New Windows installer

[Alan Taylor]

I uninstalled Pan .140 and verified the .pan2 directory was still
there.  The I re-installed Pan and everything worked fine - no problem
with "This application has
requested the Runtime to terminate it in an unusual way" even though
an old (well, same version) .Pan2 directory was there.  This was not
the case with .139, so something has been fixed in the newest version.
So, sort-of, false alarm re removing .Pan2 directory being needed.  If
you're going from .139 to .140 you have to delete something, might as
well be the whole directory.

So I didn't need to do any bisecting to zero-in on a problem.

On 20 March 2016 at 14:49, Alan Taylor <address@hidden> wrote:
>>>
>>> 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.