DXKeeper QSL queue will not populate.


James Galm
 

Hello Everyone, 

I have one log database, PJ2/W8WTS.mdb, with > 12,000 QSOs.  When new QSOs were imported, they always went into the QSL queue when I set LOTW and Add Requested from the QSL tab.  I just added some QSOs manually via the Log QSOs tab.  Their LOTW sent selector is Y.  However, they will not appear in the QSL queue when I set LOTW and Add Requested from the QSL tab.  How could this be?  I have other databases that populate individually added QSOs perfectly.  This appears to be a problem unique to the PJ2/W8WTS.mdb database.  Where can I start troubleshooting this problem?  

Thanks in advance for your help and 73, 

Jim, W8WTS


Dave AA6YQ
 

+ AA6YQ comments below
I have one log database, PJ2/W8WTS.mdb, with > 12,000 QSOs.  When new QSOs were imported, they always went into the QSL queue when I set LOTW and Add Requested from the QSL tab.  I just added some QSOs manually via the Log QSOs tab.  Their LOTW sent selector is Y.  However, they will not appear in the QSL queue when I set LOTW and Add Requested from the QSL tab.  How could this be?  I have other databases that populate individually added QSOs perfectly.  This appears to be a problem unique to the PJ2/W8WTS.mdb database.  Where can I start troubleshooting this problem?

+ On the Main window's QSL tab before you click the "Add Requested" button, to what is the "QSL Via" panel set?

+ If it's set to cards or labels or files, then only logged QSO's whose "QSL Sent" items are set to 'R' will be added to the QSL Queue.

+ If it's set to LoTW, then only QSO's whose "LoTW QSL Sent" items are set to 'R' will be added to the QSL Queue.

+ If it's set to eQSL, then only QSO's whose "eQSL QSL Sent" items are set to 'R' will be added to the QSL Queue.

+ On the "QSL Configuration" window's General tab, is the "Initialize QSL Sent to 'R' for each imported QSO" option enabled so that when you import new QSOs, the "QSL Sent" items of those QSOs will be set to 'R'?

     73,

           Dave, AA6YQ

 

 


Joe Subich, W4TV
 

On 2022-12-08 1:14 AM, James Galm wrote:

Jim,

I just added some QSOs manually via the Log QSOs tab. Their LOTW sent selector is Y.
LotW Sent = Y means that the QSO has already been sent to LotW.
DXKeeper will not add a QSO to the Upload Queue if it has already
been sent.

What did you do to cause LotW Sent to be set to "Y" when you
(presumably) entered them manually? Did you manually set LotW
Sent to Y instead of R?

The easiest thing is to check QSL -> QSL Config -> LotW ->
"Initialize LotW Sent to 'R' on each logged QSO or imported QSO"
before entering/importing QSOs.

73,

... Joe, W4TV

On 2022-12-08 1:14 AM, James Galm wrote:
Hello Everyone,
I have one log database, PJ2/W8WTS.mdb, with > 12,000 QSOs.  When new QSOs were imported, they always went into the QSL queue when I set LOTW and Add Requested from the QSL tab.  I just added some QSOs manually via the Log QSOs tab.  Their LOTW sent selector is Y.  However, they will not appear in the QSL queue when I set LOTW and Add Requested from the QSL tab.  How could this be?  I have other databases that populate individually added QSOs perfectly.  This appears to be a problem unique to the PJ2/W8WTS.mdb database.  Where can I start troubleshooting this problem?
Thanks in advance for your help and 73,
Jim, W8WTS


James Galm
 

Hello Everyone, 

I finally debugged this problem.  It took some time to find, but the root cause was that the Default Callsigns fields in DXKeeper Config Defaults tab did not match the Station Call in the Auxiliary panel of Log QSOs.  It appears that DXKeeper will not load the QSL queue with QSOs whose Station Call does not match the active default callsign.  That makes sense, as it should not create QSLs with more that one station callsign.  The imported QSOs were logged with the PJ2/W8WTS callsign, so they loaded the QSL queue.  However QSOs entered via the Log QSOs tab were logged with the default, W8WTS callsign, even though the log and database were for PJ2/W8WTS, hence they would not populate.  

The solution already existed.  There is a selection to maintain the default callsigns in the log or in the registry.  I was maintaining them in the registry, which fails when using multiple databases and logs with differing callsigns.  Once I switched to maintain the default callsigns in the log, and set the default callsigns correctly for each log and database, the QSL queue populates normally.  

Thanks and 73, 

Jim, W8WTS


Dave AA6YQ
 

+ AA6YQ comments below
I finally debugged this problem.  It took some time to find, but the root cause was that the Default Callsigns fields in DXKeeper Config Defaults tab did not match the Station Call in the Auxiliary panel of Log QSOs.  It appears that DXKeeper will not load the QSL queue with QSOs whose Station Call does not match the active default callsign.  That makes sense, as it should not create QSLs with more that one station callsign.  The imported QSOs were logged with the PJ2/W8WTS callsign, so they loaded the QSL queue.  However QSOs entered via the Log QSOs tab were logged with the default, W8WTS callsign, even though the log and database were for PJ2/W8WTS, hence they would not populate.  

The solution already existed.  There is a selection to maintain the default callsigns in the log or in the registry.  I was maintaining them in the registry, which fails when using multiple databases and logs with differing callsigns.  Once I switched to maintain the default callsigns in the log, and set the default callsigns correctly for each log and database, the QSL queue populates normally. 

+ With the "QSL Via" panel set to any value on the Main window's QSL tab, the "Add Requested" function on that tab will populate the QSL Queue with QSOs whose "Station Callsign" items don't match the "Station Callsign" specified in the upper-left corner of the Configuration window's "Defaults" tab.

+ With the "QSL Via" panel set to LoTW on the Main window's QSL tab, the "Add Requested" function on that tab will not populate the QSL Queue with QSOs whose "Station Callsign" items don't match the "Station Callsign" specified in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab. This is to ensure that all QSOs submitted in a batch to LoTW were made using the same "Station Callsign" over the air. See

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

+ Note that you did not respond to the questions I posed in order to begin better understanding your situation:

https://groups.io/g/DXLab/message/211334

+ You are of course welcome to debug problems on your own, but in complex scenarios -- like submitting QSOs to LoTW from multiple DXCC entities -- having access to the relevant source code often enables me to accelerate the process.

+ The option to store the default Station Callsign, Operator Callsign, and Owner Callsign in each log rather than in the Window Registry was introduced in DXKeeper 15.9.6, which was publicly released on 2020-12-23; the motivation was to make it easier for multiple members of a family to utilize the same instance of DXKeeper. Before then, many DXLab users - me included - successfully submitted QSOs to LoTW from multiple logs using multiple callsigns; the option to store the default Station Callsign, Operator Callsign, and Owner Callsign in each log does simplify operations in "multiple logs using multiple callsigns" scenarios.

       73,

               Dave, AA6YQ

 

 

 

 


bill steffey NY9H
 

interestingly  I am on Comcast connection,    which is "timing out" ....after 13 hops  and 23 ms. !!!! AND THAT IS TO COMCAST.COM appearing to getting lost within Comcast links...on it's way from pittsburgh to beaumeade to ashburn VA !!!! same for comcast.net !!!!! 

dxlabs continues to work fine..





On 12/12/2022 11:58 PM, Dave AA6YQ wrote:

+ AA6YQ comments below
I finally debugged this problem.  It took some time to find, but the root cause was that the Default Callsigns fields in DXKeeper Config Defaults tab did not match the Station Call in the Auxiliary panel of Log QSOs.  It appears that DXKeeper will not load the QSL queue with QSOs whose Station Call does not match the active default callsign.  That makes sense, as it should not create QSLs with more that one station callsign.  The imported QSOs were logged with the PJ2/W8WTS callsign, so they loaded the QSL queue.  However QSOs entered via the Log QSOs tab were logged with the default, W8WTS callsign, even though the log and database were for PJ2/W8WTS, hence they would not populate.  

The solution already existed.  There is a selection to maintain the default callsigns in the log or in the registry.  I was maintaining them in the registry, which fails when using multiple databases and logs with differing callsigns.  Once I switched to maintain the default callsigns in the log, and set the default callsigns correctly for each log and database, the QSL queue populates normally. 

+ With the "QSL Via" panel set to any value on the Main window's QSL tab, the "Add Requested" function on that tab will populate the QSL Queue with QSOs whose "Station Callsign" items don't match the "Station Callsign" specified in the upper-left corner of the Configuration window's "Defaults" tab.

+ With the "QSL Via" panel set to LoTW on the Main window's QSL tab, the "Add Requested" function on that tab will not populate the QSL Queue with QSOs whose "Station Callsign" items don't match the "Station Callsign" specified in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab. This is to ensure that all QSOs submitted in a batch to LoTW were made using the same "Station Callsign" over the air. See

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

+ Note that you did not respond to the questions I posed in order to begin better understanding your situation:

https://groups.io/g/DXLab/message/211334

+ You are of course welcome to debug problems on your own, but in complex scenarios -- like submitting QSOs to LoTW from multiple DXCC entities -- having access to the relevant source code often enables me to accelerate the process.

+ The option to store the default Station Callsign, Operator Callsign, and Owner Callsign in each log rather than in the Window Registry was introduced in DXKeeper 15.9.6, which was publicly released on 2020-12-23; the motivation was to make it easier for multiple members of a family to utilize the same instance of DXKeeper. Before then, many DXLab users - me included - successfully submitted QSOs to LoTW from multiple logs using multiple callsigns; the option to store the default Station Callsign, Operator Callsign, and Owner Callsign in each log does simplify operations in "multiple logs using multiple callsigns" scenarios.

       73,

               Dave, AA6YQ

 

 

 

 


Bill Pence
 

It seems the timeouts are just longer than tracert wants to see. I guess these nodes retry and continue.  The important thing is you get to dxlabsuite.com

The failures are unable to resolve or other fatal errors due to some issue with internet routing along the route. And these poor guys can not get to the appropriate tech folks to resolve since it it beyond their isp...

On Tue, Dec 13, 2022, 10:10 AM bill steffey NY9H <Ny9h@...> wrote:

interestingly  I am on Comcast connection,    which is "timing out" ....after 13 hops  and 23 ms. !!!! AND THAT IS TO COMCAST.COM appearing to getting lost within Comcast links...on it's way from pittsburgh to beaumeade to ashburn VA !!!! same for comcast.net !!!!! 

dxlabs continues to work fine..





On 12/12/2022 11:58 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
I finally debugged this problem.  It took some time to find, but the root cause was that the Default Callsigns fields in DXKeeper Config Defaults tab did not match the Station Call in the Auxiliary panel of Log QSOs.  It appears that DXKeeper will not load the QSL queue with QSOs whose Station Call does not match the active default callsign.  That makes sense, as it should not create QSLs with more that one station callsign.  The imported QSOs were logged with the PJ2/W8WTS callsign, so they loaded the QSL queue.  However QSOs entered via the Log QSOs tab were logged with the default, W8WTS callsign, even though the log and database were for PJ2/W8WTS, hence they would not populate.  

The solution already existed.  There is a selection to maintain the default callsigns in the log or in the registry.  I was maintaining them in the registry, which fails when using multiple databases and logs with differing callsigns.  Once I switched to maintain the default callsigns in the log, and set the default callsigns correctly for each log and database, the QSL queue populates normally. 

+ With the "QSL Via" panel set to any value on the Main window's QSL tab, the "Add Requested" function on that tab will populate the QSL Queue with QSOs whose "Station Callsign" items don't match the "Station Callsign" specified in the upper-left corner of the Configuration window's "Defaults" tab.

+ With the "QSL Via" panel set to LoTW on the Main window's QSL tab, the "Add Requested" function on that tab will not populate the QSL Queue with QSOs whose "Station Callsign" items don't match the "Station Callsign" specified in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab. This is to ensure that all QSOs submitted in a batch to LoTW were made using the same "Station Callsign" over the air. See

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

+ Note that you did not respond to the questions I posed in order to begin better understanding your situation:

https://groups.io/g/DXLab/message/211334

+ You are of course welcome to debug problems on your own, but in complex scenarios -- like submitting QSOs to LoTW from multiple DXCC entities -- having access to the relevant source code often enables me to accelerate the process.

+ The option to store the default Station Callsign, Operator Callsign, and Owner Callsign in each log rather than in the Window Registry was introduced in DXKeeper 15.9.6, which was publicly released on 2020-12-23; the motivation was to make it easier for multiple members of a family to utilize the same instance of DXKeeper. Before then, many DXLab users - me included - successfully submitted QSOs to LoTW from multiple logs using multiple callsigns; the option to store the default Station Callsign, Operator Callsign, and Owner Callsign in each log does simplify operations in "multiple logs using multiple callsigns" scenarios.

       73,

               Dave, AA6YQ