Hi Nate, Wow, you brought a lot of stuff to check!
I suggest to tackle the issues one by one on github. It seems the "random mult" issue (#273) hit again after one year. Could you please open issues for the input clearing on Esc and the scoring anomaly? If neither the log file nor the relevant rule were changed then the scoring must come the same result and not prompt for re-saving. During rescoring (and also at initial entry) only the second part of the log line after the received exchange is updated. This done to ensure that what the user sees (mults and points) is exactly what is stored in the log file. We could of course store only the raw QSO data in the log file, but as historically mults and points were also included this feature was kept for compatibility and a kind of user friendliness (mults/point can be check in log file without starting TLF). 73, Zoli On Sat, Aug 27, 2022 at 09:58:03PM -0500, Nate Bargmann wrote: > Apologies to Sergio Leone for hijacking his movie title. ;-) > > This weekend is the annual Kansas QSO Party and I've been putting TLF > through the paces again. I am using Git master at commit 67e2322. > > The Good: > > Escape is working well to stop a voice transmission that is in progress. > > The sound log files are now in a subdirectory of the working directory. > > The Bad: > > I had the first lock-up of TLF in recent memory, if ever, earlier today. > I am not sure if I struck Ctrl-S (now that I think about it) but TLF in > the XTerm I am using would not respond. I used 'pkill -f tlf' to dump > it and restart it. I know I had intended to Alt-Tab back to the XTerm > from Firefox to enter a call and that is when it happened. Operator or > TLF error, I'm not sure. > > Related, at one point TLF was getting sluggish while the TU CW message > was being sent with the callsign text not being cleared and the worked > before window remaining visible until after the TU message was sent. At > one point this remained for several seconds and a station was answering > and I could not type and then it returned to normal. Oddly, I didn't > see that again. There were only about 230 Qs in the log file at the > time. > > The Ugly: > > Escape is wiping out the entered data when first pressed while a CW > message is in process (I don't recall if it did the same thing on SSB). > This requires a repeat request or a good short term memory (I had to ask > for repeats when this happened). If there are users that want to > maintain the current behavior then it should be configurable. If it > already is and I missed it, that's on me. > > TLF seems to be inventing multipliers in the scoring window. The actual > ones appearing in the log file are correct but the Mul: value seemed to > increment almost without a pattern. Consequently the displayed score is > nonsensical. > > I noticed when I restarted TLF after the pkill command that it prompted > me whether to rescore the log. I answered Y and when the logging screen > came up all of the CW QSOs were set to 2 points instead of 3 (in the > KSQP CW score 3 points and SSB score 2 points each). For whatever > reason I had SSBMODE set in log_cfg.dat. Just now I commented it out > and started TLF again and did not get the rescoring prompt and my last > CW contacts are still at 3 points. > > Thankfully, the log file was backed up each time. > > I suppose this brings up another question, what value is there in > storing a point value in the log file? It seems to me that if points > are calculated by mode that the mode column should be the determining > factor. Also, mults will need to be read and calculated from each line > so doing so for the mode would seem consistent. > > I also think it is an error in judgment to be rewriting the log file in > the first place. Thankfully this bug didn't destroy my event as > Cabrillo generation was not affected. I think that TLF should only > append to the log file and the only time it is written is when the > operator performs an editing action either in TLF or an external editor. > As I see it, the log data is the most precious part of the event and I > know that most of us don't back up the log file with every disk write, > but perhaps we should! > > Anyway, these are the issues I found today. What will tomorrow bring? > > 73, Nate >
