Date   

Re: Commander won't launch

Dave AA6YQ
 

+ AA6YQ comments below
apparently in bring back a station backup from Carbonite, it overwrote with a corrupt file
+ That doesn't make me feel very confident in my own use of Carbonite as my cloud backup solution.

glad it is working though, I am quite spoiled by using these fine programs and really feel crappy when my system prevents that.

I am doubly backed up; to external hard drive and external with Carbonite; good thing because the local one was shot with errors (tried it first due to low internet speeds).

+ What kind of errors did you encounter in your local backup? I use StorageCraft Shadow Protect for automatic daily backups to a network-accessible set of hard drives. On several occasions, I have mounted a backup volume and successfully restored files.

 

It first started when trying to bring my new system back up; initially DX lab stuff was all working following directions on the wiki you sent me; but when I brought back my other files it cratered the .ocx file in question.

+  Are you saying that directing Carbonite to restore applications other than your DXLab applications damaged one of your DXLab application files?

 

Immediately after that it barfed; there was an internet outage during the restore of files from off site. Next time I have to restore from offsite, I will go to my son's house and use his better, faster  internet service.

+ In my view, making your local backup and recovery mechanism reliable should be your first priority. A cloud-based backup and recovery capability is important for disaster recovery, but its recovery is too slow for "normal" use.

            73,

                  Dave, AA6YQ


Re: Commander comport error

Dave AA6YQ
 

+ AA6YQ comments below
Couldn't say if I 'fixed' anything however this problem has been resolved. Hope it stays that way.

I uninstalled Commander and deleted its subdirectory. I did not clean Commander out of the registry.

After a fresh installation Commander now recognizes the rig like it should. No error messages. I did not do anything else to achieve this beyond yet another restart. Restarts had not helped prior to Commander's reinstall.

+ The only technical explanation I can offer is that Windows secretly maintains a "users I'd like to torture" list that evidently gets cleared when you uninstall the application it's using to torture you.

+ A less invasive experiment that you could have performed would have been to connect your transceiver directly to a USB port, rather than to the Edgeport USB bridge. I suspect that it would have worked correctly.

         73,

                Dave, AA6YQ

 


Re: Commander won't launch

David Reed
 

Apparently in bring back a station backup from Carbonite, it overwrote with a corrupt file; glad it is working though, I am quite spoiled by using these fine programs and really feel crappy when my system prevents that.

I am doubly backed up; to external hard drive and external with Carbonite; good thing because the local one was shot with errors (tried it first due to low internet speeds).

It first started when trying to bring my new system back up; initially DX lab stuff was all working following directions on the wiki you sent me; but when I brought back my other files it cratered the .ocx file in question.

Immediately after that it barfed; there was an internet outage during the restore of files from off site. Next time I have to restore from offsite, I will go to my son's house and use his better, faster  internet service.

Thanks again & 73 de Dave, W5SV

On 2/28/2021 22:32, Dave AA6YQ wrote:

+ AA6YQ comments below

VB =VisualBasic… I just figured it might be something with that… in my ignorance, but it works now…

+ Thanks, Dave. Evidently, installing VB re-registered MouseWheelControl.ocx . There's a simpler way to re-register a component, if this happens again.

+ The question now is "why did MouseWheelControl.ocx become un-registered?"

+ When did this problem first appear. What changes to you hardware or software did you make around that time?

+ I suggest checking the Windows Event Logs for signs of hardware or software failures.

73,

Dave, AA6YQ


Re: Commander comport error

k6xt
 

Couldn't say if I 'fixed' anything however this problem has been resolved. Hope it stays that way.

I uninstalled Commander and deleted its subdirectory. I did not clean Commander out of the registry.

After a fresh installation Commander now recognizes the rig like it should. No error messages. I did not do anything else to achieve this beyond yet another restart. Restarts had not helped prior to Commander's reinstall.

73 Art


Re: Commander won't launch

Dave AA6YQ
 

+ AA6YQ comments below

VB =VisualBasic… I just figured it might be something with that… in my ignorance, but it works now…

+ Thanks, Dave. Evidently, installing VB re-registered MouseWheelControl.ocx . There's a simpler way to re-register a component, if this happens again.

+ The question now is "why did MouseWheelControl.ocx become un-registered?"

+ When did this problem first appear. What changes to you hardware or software did you make around that time?

+ I suggest checking the Windows Event Logs for signs of hardware or software failures.

73,

Dave, AA6YQ


Re: Commander won't launch

David Reed
 

VB =VisualBasic… I just figured it might be something with that… in my ignorance, but it works now…

73 de W5SV - David F. Reed

On Feb 28, 2021, at 15:04, Dave AA6YQ <aa6yq@...> wrote:

+ AA6YQ comments below

meanwhile, I re-installed VB, and that seems to have fixed it...

+ What's VB?

+ I would have recommended re-registering MouseWheelControl.ocx

      73,

            Dave, AA6YQ

On 2/28/2021 9:14 AM, David Reed via groups.io wrote:
When trying to launch Commander (Via DXLab Launcher), I get the
following error:

"Component 'MouseWheelControl.ocx' or one of its dependencies not
correctly registered: a file is missing or invalid"

I have no idea beyond something got deleted or corrupted; any ideas on
how to fix it?

Thanks & 73 de Dave, W5SV








when something that previously worked stops working

Dave AA6YQ
 

There have been several recent problem reports here of the form "DXLab application function X stopped working Y weeks/months ago".

If you try a DXLab application function that you've never before utilized and it doesn't work as expected, that could well be the
result of a defect in the application that no one else has yet encountered or reported.

If you update a DXLab application to a new version, and find that a function that worked in the previous version no longer works as
expected, that's almost certainly the result of a defect in the new version of the application.

However, if a DXLab application function that was previously working suddenly stops working with no change to that application and
no change to any other DXLab application, the root cause is likely environmental -- meaning that a change to some other aspect of
your broader computing environment is responsible. Typical culprits include

- the replacement of a functioning device driver with a non-functioning device driver as the result of installing new hardware, or
of accepting a Windows Update

- the replacement of a "shared component" with a non-functioning version of that component as the result of installing another
application

As explained in "Managing Hardware and Software Upgrades" in

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

"To minimize memory consumption, Windows encourages applications to use a common set of libraries. Some of these libraries are
provided by Microsoft (e.g. MSCOMM32.DLL), whereas as others a provided by application developers (e.g. PSKCORE.DLL). Thus you may
have multiple applications installed on your PC all using the same instance of MSCOMM32.DLL to send and receive characters via a
serial port, and you may have multiple applications installed on your PC that all use the same instance of PSKCORE.DLL to modulate
and demodulate PSK. Occasionally, these libraries are updated by their authors. A Windows Update from Microsoft, for example, might
include an improved version of MSCOMM32.DLL. Installing a new PSK application, or upgrading an already-installed PSK application may
install an improved version of PSKCORE.DLL on your system. New versions of shared libraries are supposed to be backward compatible
with their predecessors, but occasionally this isn't the case. When this happens, installing a new application or upgrading an
installed application can cause other installed applications to stop working or perform poorly."

This article goes on to make specific recommendations for protecting your computing environment from these problems. While these
practices require extra work on your part, they can prevent a lot of downstream aggravation when a previously working DXLab
application stops working -- and at the worst possible time.

The motivation for this post is not to lambast anyone who has reported "likely environmental" problems here. It makes me
uncomfortable to respond to a report of adverse behavior in a DXLab application by pointing the finger at some other component or
application; I've been on the wrong end of that maneuver more times than I care to remember. Please continue to report any adverse
behavior that you encounter -- whether you suspect that it might be environmental or not -- but understand that actively maintaining
the integrity of your computing environment is essential to keeping DXLab functional whenever you need it.

73,

Dave, AA6YQ


Re: Commander comport error

Dave AA6YQ
 

+ AA6YQ comments below

On every startup Commander is twice displaying an error window saying the comport for my xcvr is invalid.

+ That error report comes from Windows; Commander is just relaying it.


Device manager shows the comport, an Edgeport-4 four port device, all 4 ports are listed. Other devices connected to different Edgeport ports act normally.

Pressing Commander - Config - Reset Radios immediately connects Commander to the radio via the correct port 4 that it could not find a moment ago.

This failure is relatively recent, maybe the past year and I've just ignored it til now. Hoping someone can help.

+ Edgeport Technical Support is the most likely source of help. At minimum, be sure you're running the most recent Edgeport device driver.

I can email an error log file showing the failures and also the Reset Radios result.

+ The errorlog would contain no more information than what you've reported above: Commander asks to open the serial port, and Windows refuses to do so.

73,

Dave, AA6YQ


Re: eQSL upload needs a timeout?

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


Re: eQSL upload needs a timeout?

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


Re: LoTW and eQSL status of QSO's uploaded from HRD Logbook

Dave AA6YQ
 

+ AA6YQ comments below

After another re-sync I don't get those errors anymore and only had about a dozen that didn't match for QSO "time". The eQSL default is 15 min, so I increased it to 30 min and then only 3 errors because they were more than 30 min, so I will check these later if I have the data somewhere to try to verify it. No big deal on that though. I'm not sure why the majority of the errors (callsign, band, mode) are no longer occurring.

+ As described in

https://www.dxlabsuite.com/dxkeeper/Help/QSL.htm#QSLing%20via%20eQSL.cc

"The Sync eQSL.cc QSLs function remembers the date and time at which the last QSL reported was uploaded to eQSL.cc; this date and time is stored in the current log and shown beneath the Sync eQSL.cc QSLs button. When activated, this function directs eQSL.cc to supply only newly-arrived QSLs, thereby minimizing the amount of information to be downloaded and inspected."

+ Unless you change the date and time specified beneath the " Sync eQSL.cc QSLs" button by double-clicking them, DXKeeper's requests to eQSL.cc won't cause eQSL.cc to report those erroneous QSOs because they were already reported.

73,

Dave, AA6YQ


Re: Commander won't launch

Dave AA6YQ
 

+ AA6YQ comments below

meanwhile, I re-installed VB, and that seems to have fixed it...

+ What's VB?

+ I would have recommended re-registering MouseWheelControl.ocx

73,

Dave, AA6YQ

On 2/28/2021 9:14 AM, David Reed via groups.io wrote:
When trying to launch Commander (Via DXLab Launcher), I get the
following error:

"Component 'MouseWheelControl.ocx' or one of its dependencies not
correctly registered: a file is missing or invalid"

I have no idea beyond something got deleted or corrupted; any ideas on
how to fix it?

Thanks & 73 de Dave, W5SV


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


Re: LoTW and eQSL status of QSO's uploaded from HRD Logbook

Norm - KC1BMD
 

After another re-sync I don't get those errors anymore and only had about a dozen that didn't match for QSO "time". The eQSL default is 15 min, so I increased it to 30 min and then only 3 errors because they were more than 30 min, so I will check these later if I have the data somewhere to try to verify it. No big deal on that though. I'm not sure why the majority of the errors (callsign, band, mode) are no longer occurring.

--
73, Norm/KC1BMD


Re: LoTW and eQSL status of QSO's uploaded from HRD Logbook

Dave AA6YQ
 

+ AA6YQ comments below

Points well taken and I need to invest the time to learn. I selected the most recent CSO's that did not have confirmation status (about 18). I had them in the add-selected area of the QSL tab but when I synchronized the QSO's and QSL's, it seemed to do more than these (I thought the action would be limited to these). LoTW sync produced no errors. eQSL produced 100+ errors. I found info for the error: " no QSO matching callsign, band, and mode". I did not modify any of these parameters and they all showed with no errors in HRD Logbook (not that it matters) which was the source of the data. I found info on how to correct the errors and will look at it but I might have overwritten the error.log because I think it might have used the same name when I ran it again right after the first time (where I had far fewer errors). Clearly I need to do more learning. I might just delete my log and re-import the HRD ADIF file again and start over, hopefully on the right path. Thanks for the info.

+ It would be better to first find the root cause of the "no QSO matching callsign, band, and mode" error when invoking "Sync eQSL QSOs". Pick one QSO that generates this error, and compare the information in your DXKeeper log with the information in eQSL.cc.

73,

Dave, AA6YQ


Re: DXKeeper - LotW Sync QSO and QSLs - Not Responding

Dave AA6YQ
 

Thanks Dave, will keep plugging.

+ Have you tried invoking an LoTW Sync operation and letting it run to completion (ignoring the "not responding" message in DXKeeper's Main window's title bar)?

73,

Dave, AA6YQ


Commander comport error

k6xt
 

Howdy group
On every startup Commander is twice displaying an error window saying the comport for my xcvr is invalid.


Device manager shows the comport, an Edgeport-4 four port device, all 4 ports are listed. Other devices connected to different Edgeport ports act normally.

Pressing Commander - Config - Reset Radios immediately connects Commander to the radio via the correct port 4 that it could not find a moment ago.

This failure is relatively recent, maybe the past year and I've just ignored it til now. Hoping someone can help.

I can email an error log file showing the failures and also the Reset Radios result.

Thanks Art K6XT


Re: DXKeeper - LotW Sync QSO and QSLs - Not Responding

Jon Gefaell
 

I always appreciate your input, Joe. Your contributions are vital in supporting DX Lab Suite users. Thank you very much for caring to respond to my missives.

I've monitored the process table and the resources being allocated and utilized. There's no mystery there, and every drop is accounted for, I assure you. 

The thing is, I've designed, built, and operated high-volume, high visibility technical operations infrastructures for decades. It was my career. Despite not being proficient with Windows to a minor fraction of a degree as I am with *nix variants, I'm quite well versed in networking. I run a Ubiquity UniFi Software Defined Network, and I do deep packet inspection with IPS/IDS and remote logging to a pair of Linux hosts (*). I analyze those logs periodically. I'm very aware of what source and targets are trafficking, on what ports, and at what times. Anything suspicious is detected and mitigated when necessary. 

My ham shack systems resources are well managed and allocated. I built it to be used and with ample headroom, as I've noted. My system runs very smoothly with no apparent issues. I have no malware infestation, no botnet participation, no untracked I/O or processes. I run a pretty tight ship for decades. It's what I do.

The issue isn't related to resource consumption or malware. It does seem like a resource blocking issue, however. As I said, it's my cross to bear, and one day perhaps I will resolve it. It's a corner case for sure. 

Very best regards! Stay warm, be well, and good DX!

(*) These used to be hosted on my own physical machines located in datacenters with tier 1 networks that routed my legacy class C direct assigned network 198.147.203.0/24.  It helps to have friends in the business. Now, they're virtual machines hosted by two separate providers. They run DNS, Email, IP tunnels, and other good things for myself and my friends. 


On Sun, Feb 28, 2021 at 06:47 AM, Joe Subich, W4TV wrote:

Looking at the high CPU consumers in Task Manager should help to
identify the suspect processes.


Re: Commander won't launch

David Reed
 

meanwhile, I re-installed VB, and that seems to have fixed it...

On 2/28/2021 9:14 AM, David Reed via groups.io wrote:
When trying to launch Commander (Via DXLab Launcher), I get the following error:

"Component 'MouseWheelControl.ocx' or one of its dependencies not correctly registered: a file is missing or invalid"

I have no idea beyond something got deleted or corrupted; any ideas on how to fix it?

Thanks & 73 de Dave, W5SV


Re: trouble with creating address file for QSL labels

Lance HP
 

On Thu, Feb 25, 2021 at 01:23 PM, Dave AA6YQ wrote:

+ As a first step, close all applications and reboot Windows. Then start the Launcher, and direct the Launcher to start DXView. Any joy?

+ If this behavior recurs, make sure you have your anti-malware and firewall configured to consider both the Launcher and DXView to be "safe".

Restarting and starting DXView worked. Thank you Dave!

2541 - 2560 of 202616