locked Incorrectly Identifying DXCC Entities Worked


Jeff - G4IUA
 

WSJT-X (v2.2.0-rc1), Log4OM v2 (2.6.1.0), JTAlert (2.16.6) – all latest releases. 

 

I’m not sure what I have set up incorrectly.  I want JTAlert to change colour to indicate a DXCC entity needed on the band on which I’m operating.  ATM I’m seeing some (but not all) DXCC entities showing in yellow when I’ve definitely worked that entity before.  Log4OM correctly confirms this.  JTAlert is pointing to the SQLite file used by Log4OM so there shouldn’t be any discrepancy there, and I’ve manually scanned it as well. 

 

In ‘Wanted DXCC/Individual Bands’ I have ‘Tracking: By Individual Band’, and ‘Any Mode’ selected.  All bands in use are ticked. As I click on a band (20, 17, 15 etc) the right hand side box shows the countries needed and the ‘Wanted’ number changes.  When I select ‘Applications/WSJT-X/JTDX’ and tick the box ‘Colour Band Activity Callsigns….alert colours’ the callsign is sometimes shown in yellow.  It’s just somehow identifying SOME already worked entities as new ones.  Note that many are correct ‘worked before’ DXCC entities and are highlighted green.  Any suggestions?

 

Jeff – G4IUA

 


John, DK9JC / AK9JC
 

I can confirm this behaviour too. Log4OM latest build here. It shows DXCC worked before as new, even after a rescan of the log. Not much of an issue here. I then work them agn, that increases the chance of a QSL. :-)


Jeff - G4IUA
 

Thanks for sharing your findings.  I'm pretty sure it happened before my brand new installation too though.  You're right John; they can always be worked again - it's just a bit wasteful!  However it is vital to have new DXCCs showing up.  I have really common ones (DL, EA, I, etc) show in in yellow sometimes and I get all excited about a new country to work, only to find I've worked hundreds of them before!


HamApps Support (VK3AMA)
 

On 26/05/2020 4:26 am, John, DK9JC / AK9JC wrote:
I can confirm this behaviour too. Log4OM latest build here. It shows DXCC worked before as new, even after a rescan of the log. Not much of an issue here. I then work them agn, that increases the chance of a QSL. :-)

Log4OmV2 is a bit of a moving target at the moment.

I will need to examine your Log4OM log file to identify what is happening.
This problem is not widespread and may be due to how your updating your Log4OM log with QSL confirmations.

Please next time this happens, Log4OM showing an entity confirmed but JTAlert not detecting that after a Log Scan, send me direct a zipped copy of your Log4OM sqlite log file along with a note of the incorrectly alerted Callsign and Band/Mode.

de Laurie VK3AMA


Jeff - G4IUA
 
Edited

Meanwhile I'm just manually going to 'Wanted DXCC/Individual Bands', highlighting the band,  finding the incorrectly identified prefix for that particular band and sending it from the 'Wanted' column to 'Not Wanted'.  Not so much a problem now that I have a reasonably large number already worked but for someone starting out it would be a real pain.

BTW updated to WSJT-X 2.2.0 rc3 and JTAlert 2.16.6 r2

Jeff - G4IUA