ericek111/Nonemm
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Open a log N1MM wrote

Browse Source 
Three things stopped it.

A contest is keyed by ContestNR, not by ContestID. ContestID is only the
ContestInstance table's primary key; DXLOG.ContestNR refers to ContestNR, which
is what N1MM's SQLWhereString matches on. The two agree in a fresh log and
drift apart in one that has been used for a while, so we were reading one
contest's header with another contest's contacts. In a real log of 56284
contacts, joining on ContestID disagreed with the contact's own ContestName
52029 times; joining on ContestNR disagreed 109 times.

N1MM names a contest per mode: CQWWCW, CQWWSSB, CQWWRTTY, never plain CQWW.
Our contests now use those names, and N1mmContestNames turns one back into a
contest and a mode when a log is opened. The name carries the mode, so it beats
the ModeCategory column. Plain CQWW still opens, because older versions wrote
it that way.

The log columns were sized by counting characters, which was too narrow for the
headers: those are drawn in the theme's font, not the grid's monospace. The
grid sizes them now, with the character count as a floor so a column of short
values does not collapse.

Bandmap spots now age from when they arrived rather than from the time written
in them. A node with a wrong clock, or one replaying its backlog on connect,
emptied the bandmap as fast as it filled it.

Checked by opening a real 56284-contact N1MM log under Xvfb and reading the
contest and contacts back.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
ericek111
2026-08-27 16:27:35 +00:00
parent b9f0166777
commit da9884ebf5
17 changed files with 315 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
docs/n1mm-interop.md
View File

@@ -52,3 +52,30 @@ leaves behind.
Do not replace the database file under a running N1MM. It does not notice and
throws on the next read.
## A contact belongs to a ContestNR, not to the table key
`ContestInstance` has two numbers: `ContestID`, the table's primary key, and
`ContestNR`. `DXLOG.ContestNR` refers to the second one. N1MM's
`ContestInstance.SQLWhereString` reads:
" ContestNR = " + this.ContestNR + " "
In a fresh log the two numbers match, so keying on either works. In a log N1MM
has been using for a while they drift apart. In one real log of 56284 contacts,
joining `DXLOG.ContestNR` to `ContestInstance.ContestID` disagreed with the
contact's own `ContestName` 52029 times; joining it to `ContestInstance.ContestNR`
disagreed 109 times.
So `ContestInstance.ContestNumber` here is `ContestNR`, and `ContestID` is
allocated separately when a contest is created.
## N1MM names a contest per mode
CQ WW is `CQWWCW`, `CQWWSSB` or `CQWWRTTY`, never plain `CQWW`. The full list
lives in the `Contest` table of any N1MM database. Nonemm writes the same names,
and `N1mmContestNames` turns one back into a contest and a mode when a log is
opened. The name carries the mode, so it beats whatever `ModeCategory` says.
Older N1MM versions wrote the CW running of CQ WW as plain `CQWW`. That name is
still in the registry, so those logs open.