[Trlog] Lost Dupesheet (version 6.78)

[Igor Sokolov]

Noticed that same problem during CQWW. It has started with the latest
versions (6.75 I think). It only happens when you close down TR and then
start it again. The cure I found is to start TRwith rescore option. Then it
is back to normal. Has somesing to do with restart.bin update I think.

73, Igor UA9CDC





> On Mon, Nov 03, 2003 at 10:45:40PM -0800, Michael Tope wrote:
>
> > Anyone have trouble with Trlog's dupe checking function in
> > SS. At W6UE we had two PC's connected in a multiport
> > network for SS. On Sunday afternoon on one of the two
> > computers (the IBM Aptiva) stopped finding dupes as if the
> > program lost its internal dupesheet. Mike, KA6SAR first
> > noticed it when he started getting "QSO B4" replies from
> > all of the callsigns on the bandmap that appeared to be
> > "fresh meat" (e.g. no asterisks in front of the callsign). As
> > soon as he realized what was going on (and mumbling
> > something about using CT instead of TRlog), he started
> > using alt-L (log search) to dupe calls, and sure enough it
> > became clear that the program wasn't duping properly.
> > The other computer in our two computer multi-port network
> > (our Dell P-133) was still tracking dupes just fine.
>
> Any idea what the free memory display was showing on that
> computer?  I haven't seen this problem before.
>
> > I don't know if it was a coincidence, but the IBM Aptiva
> > with the duping problem also seemed to be having
> > trouble handling all the activity on the multi-port. At times
> > the keyboard latency got so bad that it was almost
> > impossible to edit in the exchange window (at these
> > times it would take a few seconds between a key press
> > and the corresponding call/exchange window update).
> > This PC was getting its packet feeds over the multi-port
> > from the other logging computer which was in-turn
> > connected to our Telnet computer using the Trlog
> > packet port function.
>
> The network really shouldn't have anything to do with keyboard
> latency.  This is probably more related to not using a disk
> cache and the longer write times to the disk as the log grew.
>
> Tree
> _______________________________________________
> Trlog mailing list
> Trlog at contesting.com
> http://lists.contesting.com/mailman/listinfo/trlog