Error Logging from JTAlert to DXKeeper


Russ Ravella
 

Hi Dave,

After about 3 weeks away I just fired things up and there were a couple of s/w updates to DXL and the usual database updates which I installed.  Now, when I complete a WSJT-X QSO and log from JTAlert, I receive several error messages/ notifications as follows:

An error box appears saying:
"No QSOs were uploaded to LoTW",
"no QSOs were processed because some QSOs were duplicates or invalid"

Then a Notepad screen appears titled "LoTWResult.txt" with several lines including:
"Already uploaded QSO surpassed on line 5" and further down,
"Signing aborted.  All QSOs are already uploaded; Aborted", "No records to upload", "Final Status: No QSO written(8)"

Another status box also appears titled "DXKeeper Club Log Upload" which says:
"Upload QSO to Clublog Succeeded: Dupe"

When I click off this later, a second entry for the same QSO is placed in DXKeeper

I checked JTAlert and sure enough there was a newer version which I also installed but it had no effect on the above.  I haven changed any settings in any software, or added or deleted any software since before the issue started.  I don't see that anyone else has reported this so it must be unique to my configuration.  I would very much appreciate some help.

Thanks in advance,
Russ KR6W

DXL all current
Win10 Pro 20H2
No third party AV
TQSL V2.5.7
WSJT-X V2.3.0
JTAlert V2.16.17


Dave AA6YQ
 

+ AA6YQ comments below

After about 3 weeks away I just fired things up and there were a couple of s/w updates to DXL and the usual database updates which I installed. Now, when I complete a WSJT-X QSO and log from JTAlert, I receive several error messages/ notifications as follows:

An error box appears saying:
"No QSOs were uploaded to LoTW",
"no QSOs were processed because some QSOs were duplicates or invalid"

Then a Notepad screen appears titled "LoTWResult.txt" with several lines including:
"Already uploaded QSO surpassed on line 5" and further down, "Signing aborted. All QSOs are already uploaded; Aborted", "No records to upload", "Final Status: No QSO written(8)"

Another status box also appears titled "DXKeeper Club Log Upload" which says:
"Upload QSO to Clublog Succeeded: Dupe"

When I click off this later, a second entry for the same QSO is placed in DXKeeper

I checked JTAlert and sure enough there was a newer version which I also installed but it had no effect on the above. I haven changed any settings in any software, or added or deleted any software since before the issue started. I don't see that anyone else has reported this so it must be unique to my configuration. I would very much appreciate some help.

+ I sounds like you have things configured in a way that uploads each new QSO to LoTW and Club Log twice.

+ If you're using JT-Alert, then the Enable box should be unchecked in the WSJT-X panel on the "Spot Sources" tab of SpotCollector's Configuration window. Is that the case?

73,

Dave, AA6YQ


Russ Ravella
 

Hi Dave,

Yeah, it seems like it’s suddenly started trying to upload twice but I’m pretty darn sure I haven’t touched any settings anywhere. I confirmed the “Enable” box in SC is unchecked as requested but it would have to always have been unchecked since this has always worked ? What could be going on all of a sudden 1!?!

Thanks1
Russ

On Mar 11, 2021, at 4:08 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:

+ AA6YQ comments below

After about 3 weeks away I just fired things up and there were a couple of s/w updates to DXL and the usual database updates which I installed. Now, when I complete a WSJT-X QSO and log from JTAlert, I receive several error messages/ notifications as follows:

An error box appears saying:
"No QSOs were uploaded to LoTW",
"no QSOs were processed because some QSOs were duplicates or invalid"

Then a Notepad screen appears titled "LoTWResult.txt" with several lines including:
"Already uploaded QSO surpassed on line 5" and further down, "Signing aborted. All QSOs are already uploaded; Aborted", "No records to upload", "Final Status: No QSO written(8)"

Another status box also appears titled "DXKeeper Club Log Upload" which says:
"Upload QSO to Clublog Succeeded: Dupe"

When I click off this later, a second entry for the same QSO is placed in DXKeeper

I checked JTAlert and sure enough there was a newer version which I also installed but it had no effect on the above. I haven changed any settings in any software, or added or deleted any software since before the issue started. I don't see that anyone else has reported this so it must be unique to my configuration. I would very much appreciate some help.

+ I sounds like you have things configured in a way that uploads each new QSO to LoTW and Club Log twice.

+ If you're using JT-Alert, then the Enable box should be unchecked in the WSJT-X panel on the "Spot Sources" tab of SpotCollector's Configuration window. Is that the case?

73,

Dave, AA6YQ







Dave AA6YQ
 

+ AA6YQ comments below

Yeah, it seems like it's suddenly started trying to upload twice but I'm pretty darn sure I haven't touched any settings anywhere. I confirmed the 'Enable' box in SC is unchecked as requested but it would have to always have been unchecked since this has always worked ? What could be going on all of a sudden 1!?!

+ So that I can see what's going on, please do the following

1. on the General tab of DXKeeper's Configuration window, check the "Log debugging info" box

2. terminate DXKeeper

3. start DXKeeper, and wait for it to fully initialize

4. log a QSO with JT-Alert, and wait for this operation to fully complete

5. on the General tab of DXKeeper's Configuration window, uncheck the "Log debugging info" box

6. attach the errorlog.txt file from your DXKeeper folder to an email message, and send the email message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


Russ Ravella
 

Hello,

I wanted to follow up on this.  After posting this, I was called away out of town and took my Flex Maestro and computer to operate remotely.  Amazingly, the problem stopped happening while I was gone.  I returned home today and tried again and the double logging started happening again.  That got me thinking that while I don't remember changing this setting after I got it working, the "loopback thing" in WSJT-X was new to me so I checked it's setting in WSJT-X -> Reporting -> Outgoing interfaces: .  It was set to "Loopback 0" but I could have sworn I set it to "Ethernet 2" originally.  The whole idea of "looping back" relative to "double logging" got me thinking ...  So I set it to "Ethernet 2" and nothing logged at all !  Actually pretty good news since I was at least touching something apparently related. So I added "Ethernet 2" to "Loopback 0" and that did it!  No more double logging.  When I checked the setting again, what had originally shown in the WSJT-X drop-down as "Ethernet 2" now shows as "Ethernet_32774". Apparently WSJT-X reset it ?

I wanted to mention this here in case it's of value to anyone else.  I followed up on Laurie's reflector as well.  Of course I ended up bugging both Laurie and Dave about this while the problem was actually a setting in WSJT-X all along.  Makes me appreciate Laurie and Dave's help all the more.

Thank You again !
Russ

Windows 10 20H2, current as of today
WSJT-X v2.3.0
JTAlert v2.16.17
DXLab Suite's DXKeeper v16.0.7
Flex 6700
SmartSDR v3.1.12
(connected together by physical Ethernet switch but port forwarded through my router to enable DXLab's Commander to work remotely)

As a note, I have "Post decoded Callsigns to SpotCollector as local spots" enabled (under JTAlert -> Settings -> Manage Settings -> Applications -> DXLab Suite -> SpotCollector) with no problems.  I depend on those spots in my set-up.


Dave AA6YQ
 

+ AA6YQ comments below

I wanted to follow up on this. After posting this, I was called away out of town and took my Flex Maestro and computer to operate remotely. Amazingly, the problem stopped happening while I was gone. I returned home today and tried again and the double logging started happening again. That got me thinking that while I don't remember changing this setting after I got it working, the "loopback thing" in WSJT-X was new to me so I checked it's setting in WSJT-X -> Reporting -> Outgoing interfaces: . It was set to "Loopback 0" but I could have sworn I set it to "Ethernet 2" originally. The whole idea of "looping back" relative to "double logging" got me thinking ... So I set it to "Ethernet 2" and nothing logged at all ! Actually pretty good news since I was at least touching something apparently related. So I added "Ethernet 2" to "Loopback 0" and that did it! No more double logging. When I checked the setting again, what had originally shown in the WSJT-X drop-down as "Ethernet 2" now shows as "Ethernet_32774". Apparently WSJT-X reset it ?

I wanted to mention this here in case it's of value to anyone else. I followed up on Laurie's reflector as well. Of course I ended up bugging both Laurie and Dave about this while the problem was actually a setting in WSJT-X all along. Makes me appreciate Laurie and Dave's help all the more.

Thank You again !
Russ

Windows 10 20H2, current as of today
WSJT-X v2.3.0
JTAlert v2.16.17
DXLab Suite's DXKeeper v16.0.7
Flex 6700
SmartSDR v3.1.12
(connected together by physical Ethernet switch but port forwarded through my router to enable DXLab's Commander to work remotely)

As a note, I have "Post decoded Callsigns to SpotCollector as local spots" enabled (under JTAlert -> Settings -> Manage Settings -> Applications -> DXLab Suite -> SpotCollector) with no problems. I depend on those spots in my set-up.


+ Russ, I don't see "Outgoing Interfaces" on the Reporting tab of the Settings window in WSJT-X 2.3.0.

73,

Dave, AA6YQ


Russ Ravella
 

Screen shot emailed …

On Mar 18, 2021, at 11:14 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:

+ AA6YQ comments below

I wanted to follow up on this. After posting this, I was called away out of town and took my Flex Maestro and computer to operate remotely. Amazingly, the problem stopped happening while I was gone. I returned home today and tried again and the double logging started happening again. That got me thinking that while I don't remember changing this setting after I got it working, the "loopback thing" in WSJT-X was new to me so I checked it's setting in WSJT-X -> Reporting -> Outgoing interfaces: . It was set to "Loopback 0" but I could have sworn I set it to "Ethernet 2" originally. The whole idea of "looping back" relative to "double logging" got me thinking ... So I set it to "Ethernet 2" and nothing logged at all ! Actually pretty good news since I was at least touching something apparently related. So I added "Ethernet 2" to "Loopback 0" and that did it! No more double logging. When I checked the setting again, what had originally shown in the WSJT-X drop-down as "Ethernet 2" now shows as "Ethernet_32774". Apparently WSJT-X reset it ?

I wanted to mention this here in case it's of value to anyone else. I followed up on Laurie's reflector as well. Of course I ended up bugging both Laurie and Dave about this while the problem was actually a setting in WSJT-X all along. Makes me appreciate Laurie and Dave's help all the more.

Thank You again !
Russ

Windows 10 20H2, current as of today
WSJT-X v2.3.0
JTAlert v2.16.17
DXLab Suite's DXKeeper v16.0.7
Flex 6700
SmartSDR v3.1.12
(connected together by physical Ethernet switch but port forwarded through my router to enable DXLab's Commander to work remotely)

As a note, I have "Post decoded Callsigns to SpotCollector as local spots" enabled (under JTAlert -> Settings -> Manage Settings -> Applications -> DXLab Suite -> SpotCollector) with no problems. I depend on those spots in my set-up.


+ Russ, I don't see "Outgoing Interfaces" on the Reporting tab of the Settings window in WSJT-X 2.3.0.

73,

Dave, AA6YQ







neil_zampella
 

Dave,

you have to have a multicast IP address such as 239.255.0.1 entered into the UDP Server box, and the Outgoing Interfaces drop down appears.

Neil, KN3ILZ

On 3/19/2021 1:22 AM, Russ Ravella via groups.io wrote:
Screen shot emailed …


On Mar 18, 2021, at 11:14 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:

+ AA6YQ comments below

I wanted to follow up on this. After posting this, I was called away out of town and took my Flex Maestro and computer to operate remotely. Amazingly, the problem stopped happening while I was gone. I returned home today and tried again and the double logging started happening again. That got me thinking that while I don't remember changing this setting after I got it working, the "loopback thing" in WSJT-X was new to me so I checked it's setting in WSJT-X -> Reporting -> Outgoing interfaces: . It was set to "Loopback 0" but I could have sworn I set it to "Ethernet 2" originally. The whole idea of "looping back" relative to "double logging" got me thinking ... So I set it to "Ethernet 2" and nothing logged at all ! Actually pretty good news since I was at least touching something apparently related. So I added "Ethernet 2" to "Loopback 0" and that did it! No more double logging. When I checked the setting again, what had originally shown in the WSJT-X drop-down as "Ethernet 2" now shows as "Ethernet_32774". Apparently WSJT-X reset it ?

I wanted to mention this here in case it's of value to anyone else. I followed up on Laurie's reflector as well. Of course I ended up bugging both Laurie and Dave about this while the problem was actually a setting in WSJT-X all along. Makes me appreciate Laurie and Dave's help all the more.

Thank You again !
Russ

Windows 10 20H2, current as of today
WSJT-X v2.3.0
JTAlert v2.16.17
DXLab Suite's DXKeeper v16.0.7
Flex 6700
SmartSDR v3.1.12
(connected together by physical Ethernet switch but port forwarded through my router to enable DXLab's Commander to work remotely)

As a note, I have "Post decoded Callsigns to SpotCollector as local spots" enabled (under JTAlert -> Settings -> Manage Settings -> Applications -> DXLab Suite -> SpotCollector) with no problems. I depend on those spots in my set-up.


+ Russ, I don't see "Outgoing Interfaces" on the Reporting tab of the Settings window in WSJT-X 2.3.0.

73,

Dave, AA6YQ









g4wjs
 

On 19/03/2021 06:14, Dave AA6YQ wrote:
+ AA6YQ comments below

I wanted to follow up on this. After posting this, I was called away out of town and took my Flex Maestro and computer to operate remotely. Amazingly, the problem stopped happening while I was gone. I returned home today and tried again and the double logging started happening again. That got me thinking that while I don't remember changing this setting after I got it working, the "loopback thing" in WSJT-X was new to me so I checked it's setting in WSJT-X -> Reporting -> Outgoing interfaces: . It was set to "Loopback 0" but I could have sworn I set it to "Ethernet 2" originally. The whole idea of "looping back" relative to "double logging" got me thinking ... So I set it to "Ethernet 2" and nothing logged at all ! Actually pretty good news since I was at least touching something apparently related. So I added "Ethernet 2" to "Loopback 0" and that did it! No more double logging. When I checked the setting again, what had originally shown in the WSJT-X drop-down as "Ethernet 2" now shows as "Ethernet_32774". Apparently WSJT-X reset it ?

I wanted to mention this here in case it's of value to anyone else. I followed up on Laurie's reflector as well. Of course I ended up bugging both Laurie and Dave about this while the problem was actually a setting in WSJT-X all along. Makes me appreciate Laurie and Dave's help all the more.

Thank You again !
Russ

Windows 10 20H2, current as of today
WSJT-X v2.3.0
JTAlert v2.16.17
DXLab Suite's DXKeeper v16.0.7
Flex 6700
SmartSDR v3.1.12
(connected together by physical Ethernet switch but port forwarded through my router to enable DXLab's Commander to work remotely)

As a note, I have "Post decoded Callsigns to SpotCollector as local spots" enabled (under JTAlert -> Settings -> Manage Settings -> Applications -> DXLab Suite -> SpotCollector) with no problems. I depend on those spots in my set-up.


+ Russ, I don't see "Outgoing Interfaces" on the Reporting tab of the Settings window in WSJT-X 2.3.0.

73,

Dave, AA6YQ
Hi Dave,

specifying the network interface(s) datagrams are sent on is only required for multicast group addresses, for unicast addresses the routing is determined by the networking infrastructure. Since SpotCollector does not support multicast no one using SpotCollector as a UDP server for WSJT-X should be using a multicast group address as a UDP destination in WSJT-X.

73
Bill
G4WJS.




--
73

Bill

G4WJS.


Joe Subich, W4TV
 

On 2021-03-19 6:45 AM, g4wjs wrote:
no one using SpotCollector as a UDP server for WSJT-X should be using
a multicast group address as a UDP destination in WSJT-X.
Bill,

Really? Works just fine for me with WSJTX 2.4.0-rc3, JT Alert
2.16.17 and SpotCollector with UDP Server 239.255.01, Port 2237,
and outgoing interfaces: wireless_0, loopback_6


73,

... Joe, W4TV


On 2021-03-19 6:45 AM, g4wjs wrote:
Hi Dave,
specifying the network interface(s) datagrams are sent on is only required for multicast group addresses, for unicast addresses the routing is determined by the networking infrastructure. Since SpotCollector does not support multicast no one using SpotCollector as a UDP server for WSJT-X should be using a multicast group address as a UDP destination in WSJT-X.
73
Bill
G4WJS.


g4wjs
 

On 19/03/2021 13:23, Joe Subich, W4TV wrote:

On 2021-03-19 6:45 AM, g4wjs wrote:
no one using SpotCollector as a UDP server for WSJT-X should be using
a multicast group address as a UDP destination in WSJT-X.
Bill,

Really?  Works just fine for me with WSJTX 2.4.0-rc3, JT Alert
2.16.17 and SpotCollector with UDP Server 239.255.01, Port 2237,
and outgoing interfaces: wireless_0, loopback_6


73,

   ... Joe, W4TV


On 2021-03-19 6:45 AM, g4wjs wrote:

Hi Dave,

specifying the network interface(s) datagrams are sent on is only required for multicast group addresses, for unicast addresses the routing is determined by the networking infrastructure. Since SpotCollector does not support multicast no one using SpotCollector as a UDP server for WSJT-X should be using a multicast group address as a UDP destination in WSJT-X.

73
Bill
G4WJS.

Hi Joe,

OK, I can see how that might work, but I have to ask why you are using multicast and also why you are having WSJT-X send traffic on two separate network interfaces. That seems a recipe for duplicate traffic to any server listening on all interfaces on the local machine.

73
Bill
G4WJS.


--
73

Bill

G4WJS.


Joe Subich, W4TV
 

but I have to ask why you are using multicast and also why you are
having WSJT-X send traffic on two separate network interfaces.
Seems to me I saw that from *you* on the WSJTX list in regard to
JTAlert when 2.3.0(?) added multicast support.

73,

... Joe, W4TV


On 2021-03-19 9:26 AM, g4wjs wrote:
On 19/03/2021 13:23, Joe Subich, W4TV wrote:

On 2021-03-19 6:45 AM, g4wjs wrote:
no one using SpotCollector as a UDP server for WSJT-X should be using
a multicast group address as a UDP destination in WSJT-X.
Bill,

Really?  Works just fine for me with WSJTX 2.4.0-rc3, JT Alert
2.16.17 and SpotCollector with UDP Server 239.255.01, Port 2237,
and outgoing interfaces: wireless_0, loopback_6


73,

   ... Joe, W4TV


On 2021-03-19 6:45 AM, g4wjs wrote:

Hi Dave,

specifying the network interface(s) datagrams are sent on is only required for multicast group addresses, for unicast addresses the routing is determined by the networking infrastructure. Since SpotCollector does not support multicast no one using SpotCollector as a UDP server for WSJT-X should be using a multicast group address as a UDP destination in WSJT-X.

73
Bill
G4WJS.
Hi Joe,
OK, I can see how that might work, but I have to ask why you are using multicast and also why you are having WSJT-X send traffic on two separate network interfaces. That seems a recipe for duplicate traffic to any server listening on all interfaces on the local machine.
73
Bill
G4WJS.
--
73
Bill
G4WJS.


g4wjs
 

On 19/03/2021 13:53, Joe Subich, W4TV wrote:
but I have to ask why you are using multicast and also why you are
having WSJT-X send traffic on two separate network interfaces.
Seems to me I saw that from *you* on the WSJTX list in regard to
JTAlert when 2.3.0(?) added multicast support.

73,

   ... Joe, W4TV


On 2021-03-19 9:26 AM, g4wjs wrote:
On 19/03/2021 13:23, Joe Subich, W4TV wrote:

On 2021-03-19 6:45 AM, g4wjs wrote:
no one using SpotCollector as a UDP server for WSJT-X should be using
a multicast group address as a UDP destination in WSJT-X.
Bill,

Really?  Works just fine for me with WSJTX 2.4.0-rc3, JT Alert
2.16.17 and SpotCollector with UDP Server 239.255.01, Port 2237,
and outgoing interfaces: wireless_0, loopback_6


73,

   ... Joe, W4TV


On 2021-03-19 6:45 AM, g4wjs wrote:

Hi Dave,

specifying the network interface(s) datagrams are sent on is only required for multicast group addresses, for unicast addresses the routing is determined by the networking infrastructure. Since SpotCollector does not support multicast no one using SpotCollector as a UDP server for WSJT-X should be using a multicast group address as a UDP destination in WSJT-X.

73
Bill
G4WJS.

Hi Joe,

OK, I can see how that might work, but I have to ask why you are using multicast and also why you are having WSJT-X send traffic on two separate network interfaces. That seems a recipe for duplicate traffic to any server listening on all interfaces on the local machine.

73
Bill
G4WJS.

Hi Joe,

yes it does but I though we were discussing SpotCollector as the server for WSJT-X clients.


--
73

Bill

G4WJS.


Dave AA6YQ
 

+ AA6YQ comments below

you have to have a multicast IP address such as 239.255.0.1 entered into the UDP Server box, and the Outgoing Interfaces drop down appears.

+ Thanks for the explanation, Neil!

73,

Dave, AA6YQ


Dave AA6YQ
 

+ AA6YQ comments below

specifying the network interface(s) datagrams are sent on is only required for multicast group addresses, for unicast addresses the routing is determined by the networking infrastructure. Since SpotCollector does not support multicast no one using SpotCollector as a UDP server for WSJT-X should be using a multicast group address as a UDP destination in WSJT-X.

+ Russ is using JT-Alert to interoperate with WSJT-X (see subject), not SpotCollector. SpotCollector's capabilities are no more relevant in this configuration than its ability to automatically land aircraft in dense fog.

73,

Dave, AA6YQ


Dave AA6YQ
 

Summary:

1. Russ is using JTAlert with WSJT-X and DXLab.

2. Russ reported that each QSO logged from JTAlert to DXKeeper was creating two QSOs in DXKeeper

3. An analysis of DXKeeper's errorlog showed that DXKeeper was receiving two "log QSOs" directives

4. Russ found an "Outgoing Interfaces" setting in WSJT-X that evidently caused the double-logging

5. I wanted to be sure that setting was properly documented in "Getting Started with K1JT modes using WSJT-X, JTAlert, and DXLab"

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

but could not find the "Outgoing Interfaces" setting in my instance of WSJT-X

6. Now that I understand that the "Outgoing Interfaces" setting only appears if the "UDP Server" address is set to a multicast address, I have updated the instructions cited above to suggest setting the "UDP Server" address to 127.0.0.1, which will prevent the double-logging.

Note: Configuration instructions in "Getting Started with DXLab" suggest a basic configuration suitable for most users. They do not cover all usage scenarios, for example hosting WSJT-X and JTAlert on different computers.

73,

Dave, AA6YQ


Joe Subich, W4TV
 

Hi Joe,

yes it does but I though we were discussing SpotCollector as the
server for WSJT-X clients.
The original poster indicated the use of WSJTX, JTAlert and SC:

Windows 10 20H2, current as of today
WSJT-X v2.3.0
JTAlert v2.16.17
DXLab Suite's DXKeeper v16.0.7
Flex 6700
SmartSDR v3.1.12
(connected together by physical Ethernet switch but port forwarded
through my router to enable DXLab's Commander to work remotely)
As a note, I have "Post decoded Callsigns to SpotCollector as local spots" enabled (under JTAlert -> Settings -> Manage Settings -> Applications -> DXLab Suite -> SpotCollector) with no problems. I depend on those spots in my set-up.
73,

... Joe, W4TV


On 2021-03-19 10:50 AM, g4wjs wrote:
On 19/03/2021 13:53, Joe Subich, W4TV wrote:
but I have to ask why you are using multicast and also why you are
having WSJT-X send traffic on two separate network interfaces.
Seems to me I saw that from *you* on the WSJTX list in regard to
JTAlert when 2.3.0(?) added multicast support.

73,

   ... Joe, W4TV


On 2021-03-19 9:26 AM, g4wjs wrote:
On 19/03/2021 13:23, Joe Subich, W4TV wrote:

On 2021-03-19 6:45 AM, g4wjs wrote:
no one using SpotCollector as a UDP server for WSJT-X should be using
a multicast group address as a UDP destination in WSJT-X.
Bill,

Really?  Works just fine for me with WSJTX 2.4.0-rc3, JT Alert
2.16.17 and SpotCollector with UDP Server 239.255.01, Port 2237,
and outgoing interfaces: wireless_0, loopback_6


73,

   ... Joe, W4TV


On 2021-03-19 6:45 AM, g4wjs wrote:

Hi Dave,

specifying the network interface(s) datagrams are sent on is only required for multicast group addresses, for unicast addresses the routing is determined by the networking infrastructure. Since SpotCollector does not support multicast no one using SpotCollector as a UDP server for WSJT-X should be using a multicast group address as a UDP destination in WSJT-X.

73
Bill
G4WJS.
Hi Joe,

OK, I can see how that might work, but I have to ask why you are using multicast and also why you are having WSJT-X send traffic on two separate network interfaces. That seems a recipe for duplicate traffic to any server listening on all interfaces on the local machine.

73
Bill
G4WJS.
Hi Joe,
yes it does but I though we were discussing SpotCollector as the server for WSJT-X clients.


g4wjs
 

On 19/03/2021 17:44, Dave AA6YQ wrote:
Summary:

1. Russ is using JTAlert with WSJT-X and DXLab.

2. Russ reported that each QSO logged from JTAlert to DXKeeper was creating two QSOs in DXKeeper

3. An analysis of DXKeeper's errorlog showed that DXKeeper was receiving two "log QSOs" directives

4. Russ found an "Outgoing Interfaces" setting in WSJT-X that evidently caused the double-logging

5. I wanted to be sure that setting was properly documented in "Getting Started with K1JT modes using WSJT-X, JTAlert, and DXLab"

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

but could not find the "Outgoing Interfaces" setting in my instance of WSJT-X

6. Now that I understand that the "Outgoing Interfaces" setting only appears if the "UDP Server" address is set to a multicast address, I have updated the instructions cited above to suggest setting the "UDP Server" address to 127.0.0.1, which will prevent the double-logging.

Note: Configuration instructions in "Getting Started with DXLab" suggest a basic configuration suitable for most users. They do not cover all usage scenarios, for example hosting WSJT-X and JTAlert on different computers.

73,

Dave, AA6YQ
Hi Dave and Russ,

I'm not sure the "solution" mentioned in this thread is really the right one. If double logging was happening then either two servers were receiving logged QSO datagrams, or one server was receiving them twice. The former is quite possible when using multicast and the solution would be to configure one of the servers not to convey logged QSOs to DXKeeper. The latter could be due to a combination of the server listening on all local interfaces and WSJT-X being configured to send datagrams to more than one local interface (e.g. the loopback interface and a local subnet interface).

Reducing the outgoing network interfaces to just one could fix either of those issues but for the former it is not the right solution, and for the latter I would expect a multicast UDP server to have some control over which local network interfaces it listens on. For sure with the latter, and no such listening control, such a server is going to be prone to duplicate actions.



--
73

Bill

G4WJS.


Dave AA6YQ
 

+ AA6YQ comments below

I'm not sure the "solution" mentioned in this thread is really the right one. If double logging was happening then either two servers were receiving logged QSO datagrams, or one server was receiving them twice.
The former is quite possible when using multicast and the solution would be to configure one of the servers not to convey logged QSOs to DXKeeper. The latter could be due to a combination of the server listening on all local interfaces and WSJT-X being configured to send datagrams to more than one local interface (e.g. the loopback interface and a local subnet interface).

Reducing the outgoing network interfaces to just one could fix either of those issues but for the former it is not the right solution, and for the latter I would expect a multicast UDP server to have some control over which local network interfaces it listens on. For sure with the latter, and no such listening control, such a server is going to be prone to duplicate actions.

+ The configuration instructions in

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

+ will remain limited to the most common case: WSJT-X and JT-Alert hosted on the same computer.

+ If someone writes an article describing the effective use of multicast UDP in more complex topologies, I will be happy to add it to "Getting Started with DXLab".

73,

Dave, AA6YQ