开云体育

I have one (out of three) spot sources that regularly times out, but the indicator remains green in the spot source status tab......when I open that source window, it says connections timed

Thanks Dave, I was on 17.9.7, but updated to the latest and that fixed it. I have nine “not found in log(s)” I have to figure out, but five of those are my call from IOTAs I activated and received

I did not submit an entry for 2024 and will not do so in the future until various participant unfriendly rules/policies are changed. If there is a claimed score listed it is incomplete (only 10

perhaps, "create debug log" or "save debug info" and then refer to it as "debug log" in the title bar and the help files ... Not unless one is having a regular problem. The error/debug log can get

Except for US issued callsigns, the data is user supplied. US callsigns come from the FCC ULS database. 73, ... Joe, W4TV

off topic, but congrats Joe on your FB DX Marathon score !!!!

Confirmed. Both callsigns have xml data designating <dxcc>54</dxcc> de Laurie VK3AMA

Instructions would be more consistent if the "log debugging info" check boxes were retitled "error log".? You instructions and commentary refer often to "error log", but one has to search and read to

So, where does QRZ get the info? R2FC’s page shows Kaliningrad as the location as you noted. The grid square shown on the Detail page matches the grid square for Kaliningrad. The same for PJ4JA. The

Check R2FC or UA2FL ... QRZ shows "Russia" beside the flag with those callsigns. The others show Kaliningrad. 73, ... Joe, W4TV

Not likely So does R2F and R2K as well as U2F and U2K along with R[B-I]2F, R[B-I]2K, U[B-I]2F and U[B-I]2K 73, ... Joe, W4TV

Thank you for all you do and your always very timely responses. Especially thanks, for your patience with us. Guy K4CNF [email protected]> wrote:

Dave, Other than the PJ4JA, it would have to have been one of the Kalingrad contacts which initially was logged as European Russia (and corrected by Club Log).? Going back within my log for the most

+ more AA6YQ comments below + I completely agree. With no override defined for PJ4JA and its Configuration window's Callbook tab configured to use QRZ, DXKeeper would behave identically if a CW QSO

Correct. To be fair, JTAlert is not knowingly logging an incorrect Dxcc entity. It is logging what it has been told by QRZ. JTAlert has no knowledge as to the correctness of the data QRZ has provided.

+ AA6YQ comments below + Thanks, Laurie. You're saying that if the user has "QRZ XML lookup" enabled in JTAlert and logs a QSO with PJ4JA, that because of the incorrect DXCC entity information in QRZ,

if the callsign in question is PJ4JA then it will be logged as Curacao instead of Bonaire if the user has the QRZ XML lookup enabled as that listing is broken. The PJ4JA record has an incorrect dxcc

Problem reports are welcome here; sometimes they're the result of a defect in an application, and sometimes they are the result of a deficiency in the documentation. Either way, repairing them makes

+ AA6YQ comments below + As I posted here late last month, IOTA again changed the format of the .csv file exported from IOTA.org: https://gro

I have tried to update my IOTA status several times using the .csv file downloaded from the IOTA website’s MY IOTA/DOWNLOAD QSOS, using the Update button in DXKeeper’s Check Progress/IOTA panel