<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">As far as I know, and assuming nothing
has changed in this area (and if it has, I shall want to know by
whom), DXSpider uses wpxloc.raw to determine the DXSpider "country
number" - which is not to be confused with any other (more modern)
number. I believe that the wpxloc.raw (originally from AK!A
PacketCluster) had the only unique "country number" for many
years. So 10 or so years later, when someone decided that needed a
country number for logging and contest programs, they decided to
invent some other number (eg DXCC number). This has been a source
of some confusion ever since. <br>
<br>
Wpxloc.raw and cty.dat are generated at the same time and from the
same database by the same person - who has gone to a LOT of
trouble to make this all possible. And as I have said before:
please treat Jim AD1C very gently because he has been providing
this service for the Amateur Radio community and hacking him off
will not be helpful to anyone. <br>
<br>
It is important that wpxloc.raw and cty.dat are BOTH downloaded
and then run through /spider/perl/create_sysop.pl AND then a
load/prefix command is given to the node in a console connection
(or the node is restarted). This the only reliable way of
generating a prefix file. Usually, if one downloads one file and
not the other, then create_prefix.pl will fail. But sometimes it
won't. Then load/prefix might fail, but sometimes not. The
solution is to always download BOTH files.<br>
<br>
Having got that off my chest: (only) spots generated by local
users on a node and NEW incoming spots are stored in the spot
file(s) and that's the only time the country number is stored. <br>
<br>
If you can point me to where you think the problem is (maybe
offline) I'll have a look at it. And if it is wrong, then I shall
speak quite sternly to the culprit. <br>
<br>
73 Dirk G1TLH<br>
<br>
On 02/05/2022 19:14, Kin via Dxspider-support wrote:<br>
</div>
<blockquote type="cite"
cite="mid:53de010c-27e5-a513-5da6-c97f7b004e80@cronux.net">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p><font face="Calibri"><font face="Courier New, Courier,
monospace">Hi Dirk,<br>
<br>
I've been seeing for a while that some callsigns are shown
with the wrong entity number, although in the cty.dat they
are correctly assigned.<br>
I have looked at the code and I think you are using the
information from cty.dat to assign the entity number. <br>
<br>
Here is an example where you can see the entity that arrives
in the spot and the one that should appear:</font></font></p>
<p><font face="Calibri"><font face="Courier New, Courier,
monospace">2022-05-02-02T08:27:33 - KG6JDX: 226 -> 107<br>
2022-05-02-02T08:27:56 - RP77AB: 179 -> 182<br>
2022-05-02-02T11:12:22 - WB4JTT: 226 -> 112<br>
2022-05-02-02T13:04:04 - R9MA/1: 182 -> 179<br>
2022-05-02-02T17:11:28 - K2GT: 226 -> 112<br>
2022-05-02-02T17:43:19 - W5ERV: 226 -> 117</font></font></p>
<p><font face="Calibri"><font face="Courier New, Courier,
monospace">Could you tell me if it's normal that it doesn't
update them?<br>
<br>
Regards,<br>
<br>
Kin</font><br>
</font><br>
</p>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Dxspider-support mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dxspider-support@tobit.co.uk">Dxspider-support@tobit.co.uk</a>
<a class="moz-txt-link-freetext" href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a>
</pre>
</blockquote>
<br>
</body>
</html>