TLF should calculate points and multis on every start

[dl1jbe]

On restart with an existing not empty logfile TLF does not calculate points according to the actual contest rules but just reads them from what was recorded in the logfile in former runs (see discussion in Issue #178).

[dl1jbe]

Same problem exists for scoring multis.

[zcsahok]

At least for the display it would make sense to keep the score/multi info in the log line. (the latter was missing in the screenshot in #247 as I bypassed the native multi handling) Whether to write the info back to the log (update the record) or just keep it in qsos[] (in-memory) is to be decided.

[dl1jbe]

Hmm. The log line display reads the data from the file not from qsos[] (see scroll_log()). So there is some work to be done either in rewriting the log file on every start or in the display code.

[zcsahok]

I see. But if qsos[] holds the same data (minus recalculated fields) as the log file, then it could be used to get the lines.
Just an idea.

[dl1jbe]

Right. I am just looking to make sure it has no side effects so that we do not break something different.

[dl1jbe]

Some further thoughts:

• As soon as we calculate points and multis on every start writing them in the log file makes no longer sense. That can be gone in the long run, but having a different log format would be a severe change in TLFs external behavior. The same goes for the automatically recalculation on every start.

• The planned change has a second effect. The pure log file without points and multis are worthless without the corresponding CTY.dat and rules file. That would make the way some people organize their contests (all logs in a single directory) nearly useless - updating any of the files would change the contest results for ANY contest in that directory.

Both points - changed log file and dependency on a complete set of related files - is a serious change of TLFs behavior and usage. Such a change is normally related to a major version change to TLF-2.x and should not done on the fly in a TLF-1.5.x or something. And if we want to go that way to a new major version (I am not against it) we should make sure to incorporate ALL the serious changes we already see now (Multi handling, external scripting, .....). Otherwise we are on the way to TLF-3.x, 4.x, 5.x ... shortly after.

[airween]

As soon as we calculate points and multis on every start writing them in the log file makes no longer sense. - agree, but I'm not afraid this can makes any problem. Just write back the correct points and multis to logfile. To make a backup during the re-score event can avoid the data loss.

[ha5se]

Let me add some more aspects:

The planned change has a second effect. The pure log file without points and multis are worthless without the corresponding CTY.dat and rules file. That would make the way some people organize their contests (all logs in a single directory) nearly useless - updating any of the files would change the contest results for ANY contest in that directory.

I think this is not much loss.

• During contest, it is a nice feature to continuously follow how your points continuously grow, and how your points/mults split among bands. However, shortly after the contest when the organizers check and re-score logs, and publish final results, the points and multipliers in your own calculation become irrelevant, usually also invalid, since you very likely lost points and multipliers for some mistakes, or just because your QSO was not in at least five other logs...
• For minor mistakes, like wrong exchange received, the QSO itself still may remain valid, that is, both parties can verify it as valid, when callsign and report received correctly on both ends. However, still worse, later, even after years, you can get a notice from some other parties that he completely rejects your QSO. This may be due to wrong date, not in log, wrong call, etc.
• Of course everybody is supposed to keep log in some format -- even paper, or cbr, or any other format. However, in order to keep track of such lost points or contacts, IMHO the only solution is to import contest (and other partial) logs into a single log program that is much more suitable for such follow-up tasks, and also keep track of QSLs, can generate many statistics, including actual accumulated DXCC table.
• Also I am keeping my partial logs, mainly because I am too lazy to delete it right after importing into the accumulated log. However, there is the original CBR also available, with claimed score, to compare this years claimed score to that of previus years. Also per-hour rate and similar data remain valid independent of dxcc table.
• IMHO, re-scoring a very old contest log using the current dxcc table would not make much difference, since: a) the changes are usually for entities that you very seldom work with during a contest, b) even considering the nearest big change some 30 years ago when DM joined, DL, while OM split from OK, the miscalculation would probably still be much less than the difference between the old official result and the re-calculated one using actual dxcc table.

[dl1jbe]

I can see your points, but what I learned in the last years with TLF is that there are quite a lot of people with quite a lot of different working styles out there. So their mileage may vary.

At least we should make clear that TLF will behave seriously different than before.

[zcsahok]

Shall we postpone this after the next release?

[dl1jbe]

Shall we postpone this after the next release?

I would at least not make it a blocker. Looking deeper into it there are quite some related problems which should not be solved in haste.

[airween]

Meantime I figured out something: we should introduce a new CLI option, and if user starts tlf with that, it just reads the current logfile, and re-scores it (I mean tlf reviews the multis and scores) based on the rules, then exits (like tlf -i or tlf --import).

It needs an explicit user interaction so I assume user knows what she/he does, eg. he/she makes a backup before...

Any idea?