Topics

eQSL upload needs a timeout?


AB2ZY
 

Persistent problem for a number of months.

QSO batches numbering in the hundreds after a contest and uploaded to eQSL will randomly halt.  When this happens, DXKeeper  hangs indefinitely and the process must be killed and restarted.  This is pretty consistent. You can get around the problem by selecting only 30 or 50 QSOs at a time, but this is pointless when there are 350 in the queue. I only upload to eQSL as a favor for others as I don't need it so I've just stopped doing it. 

If I understand the eQSL interface you are doing a POST for each QSO in the queue. Needs a timeout so that if it doesn't completed in a reasonable time, the batch is aborted and control returned to DXKeeper.

FYI. YMMV.

Al
AB2ZY


Dave AA6YQ
 

+ AA6YQ comments below

Persistent problem for a number of months.

+ It would have been useful to know exactly when this behavior began, as that would have enabled correlation with changes to your hardware or software.

QSO batches numbering in the hundreds after a contest and uploaded to eQSL will randomly halt. When this happens, DXKeeper hangs indefinitely and the process must be killed and restarted. This is pretty consistent. You can get around the problem by selecting only 30 or 50 QSOs at a time, but this is pointless when there are 350 in the queue. I only upload to eQSL as a favor for others as I don't need it so I've just stopped doing it.

If I understand the eQSL interface you are doing a POST for each QSO in the queue. Needs a timeout so that if it doesn't completed in a reasonable time, the batch is aborted and control returned to DXKeeper.

+ There's a 60-second timeout for each QSO being submitted to eQSL.cc. If DXKeeper is hanging, that can only mean that the Microsoft component being directed to upload the ADIF file (MSINET.OCX) is hanging.

+ The most recent change to DXKeeper's eQSL upload mechanism was made in DXKeeper 15.2.5 in late November 2019, and that change improved error checking. No one else has reported a DXKeeper hang when invoking "Upload to eQSL.cc" -- ever. Thus it's likely that a change in your hardware or software configuration around the time you first observed this behavior is responsible. See "Managing Hardware and Software Upgrades" in

https://www.dxlabsuite.com/dxlabwiki/HardwareSoftwareUpgrades

+ While you're debugging this, you can submit relatively large numbers of QSOs to eQSL using the procedure described in "Exporting to eQSL.cc" here:

https://www.dxlabsuite.com/dxkeeper/Help/Export.htm#exporting%20to%20eQSL.cc

73,

Dave, AA6YQ


Dave AA6YQ
 

@ more AA6YQ comments below

Persistent problem for a number of months.

+ It would have been useful to know exactly when this behavior began, as that would have enabled correlation with changes to your hardware or software.

QSO batches numbering in the hundreds after a contest and uploaded to eQSL will randomly halt. When this happens, DXKeeper hangs indefinitely and the process must be killed and restarted. This is pretty consistent. You can get around the problem by selecting only 30 or 50 QSOs at a time, but this is pointless when there are 350 in the queue. I only upload to eQSL as a favor for others as I don't need it so I've just stopped doing it.

If I understand the eQSL interface you are doing a POST for each QSO in the queue. Needs a timeout so that if it doesn't completed in a reasonable time, the batch is aborted and control returned to DXKeeper.

+ There's a 60-second timeout for each QSO being submitted to eQSL.cc. If DXKeeper is hanging, that can only mean that the Microsoft component being directed to upload the ADIF file (MSINET.OCX) is hanging.

+ The most recent change to DXKeeper's eQSL upload mechanism was made in DXKeeper 15.2.5 in late November 2019, and that change improved error checking. No one else has reported a DXKeeper hang when invoking "Upload to eQSL.cc" -- ever. Thus it's likely that a change in your hardware or software configuration around the time you first observed this behavior is responsible. See "Managing Hardware and Software Upgrades" in

https://www.dxlabsuite.com/dxlabwiki/HardwareSoftwareUpgrades

+ While you're debugging this, you can submit relatively large numbers of QSOs to eQSL using the procedure described in "Exporting to eQSL.cc" here:

https://www.dxlabsuite.com/dxkeeper/Help/Export.htm#exporting%20to%20eQSL.cc

@ The version of MSINET.OCX installed by DXKeeper is 6.1.97.82

@ If an application you installed around the time this behavior began replaced this version with an earlier version of MSINET.OCX, that might explain the behavior you report above.

73,

Dave, AA6YQ


AB2ZY
 
Edited

Like I said, FYI. If no one else is reporting this then it must be my computer. FWIW, this is a older Win7 machine that is dedicated to shack duties. The only applications installed are DXlab, N1MM, WSJT, MMTTY, uHAM Router and whatever software is needed for an RSPdx SDR I bought last year. MSINET.OCX is at version 6.01.9782, which is no surprise as ActiveX has been deprecated for some time now and no new applications are being developed with it. I'm quite sure DXLab is the only application using MSINET on that computer.

Thanks,

Al
AB2ZY