Dave: will do when at the computer
Phil: I had to restart PathFinder to make it work.
--
Björn, SM0SBL

+ AA6YQ comments below

Of all my email accounts, the only outgoing SMTP server (Yahoo, Network Solutions, Google) I could make work was Google.  Google is not liking the third-party app logging in due to it's impression of Spotcollector's security bits. 

+ What leads you to the conclusion that Google has a problem with SpotCollector's "security bits"?

 

+ Please review the recommended Gmail settings here:

https://www.dxlabsuite.com/spotcollector/Help/ConfigurationNotifications.htm#Settings%20for%20popular%20outgoing%20email%20servers

Anyone else have this problem? 

+ No one else has reported a problem here.

Are there any free outgoing mail servers? 

+ Google "Free outgoing mail servers".

Do I have to host my own domain name and mail server to make this work?

+ No one else has reported having to do that.

         73,

                 Dave, AA6YQ

Of all my email accounts, the only outgoing SMTP server (Yahoo, Network Solutions, Google) I could make work was Google.  Google is not liking the third-party app logging in due to it's impression of Spotcollector's security bits.  Anyone else have this problem?  Are there any free outgoing mail servers?  Do I have to host my own domain name and mail server to make this work?

Thanks, Paul / W7IV

+ AA6YQ comments below

Recently I've noticed that SpotCollector will get into a state where it's now scrolled all the way to the bottom, and to get it back I have to change Sort to something else and back to Rcv, and it'll be good for awhile.

+ Are you saying that neither the vertical scroll bar along the right side of the Spot Database Display nor the "VCR-like controls" in the Main window's upper-right corner are functional?

         73,

              Dave, AA6YQ

+ AA6YQ comments below

I think Dave is sniffing around trying to figure out why so few of us are having a difficulty with this recent change in recording modes.   It doesn't seem to be a problem for most.

+ It's Windows that is reporting "insufficient system resources". Every log that's been sent to me has been immediately upgraded by directing my instance of DXKeeper to open it. Since only a small fraction of DXLab users have reported this behavior, it may be a function of other applications you have running.

        73,

               Dave, AA6YQ

    

+ AA6YQ comments below

Jerry, you are lucky, Not only will ver. 16.1.5 not open I can no longer o back to 15.9.9.

+ Please place your log file in a zip archive, attach the zip archive to an email message, and send the email message to me via

aa6yq (at) ambersoft.com

+ What's stopping from your reverting to DXKeeper 15.9.9?

       73,

              Dave, AA6YQ

I typically have SC set to sort "Rcv", meaning the most recent spot is at the top.

Recently I've noticed that SpotCollector will get into a state where it's now scrolled all the way to the bottom, and to get it back I have to change Sort to something else and back to Rcv, and it'll be good for awhile.

Any ideas?

73 de KM8V

Tom,

Have patience.   Despite my initial concern, Dave was able to modify my recently backed up log and has sent in back to me within a few hours.   That's very little downtime, but the benefits of an integrated DXLab Suite of apps including DXKeeper are worth the investment of some time and effort.   

Thank you again, Dave.

        73,     Jerry     K7VIT

PS     I think Dave is sniffing around trying to figure out why so few of us are having a difficulty with this recent change in recording modes.   It doesn't seem to be a problem for most.

+ AA6YQ comments below

I upgraded to version 16.1.5 today, and when I started it, I got a window saying it was "EXPANDING QSO MODE FIELD WIDTH TO 12"
Then I got the error message

Existing fields were not successfully updated due to an error noted in the errorlog.txt file; the specified log cannot be opened

In error log.txt, I see

program error 3035 in module DXLogModule.UpdateFields, theState = 105, UpdateFields = 4, SaveUpdateFields = : System resource exceeded.

Any suggestions?

+ Please place your log file (probably N9EP.mdb) in a zip archive, attach the zip archive to an email message, and send the email message to me via

aa6yq (at) ambersoft.com

         73,

            Dave, AA6YQ

hi folks:
I upgraded to version 16.1.5 today, and when I started it, I got a window saying it was "EXPANDING QSO MODE FIELD WIDTH TO 12"
Then I got the error message

Existing fields were not successfully updated due to an error noted in the errorlog.txt file; the specified log cannot be opened

In error log.txt, I see

program error 3035 in module DXLogModule.UpdateFields, theState = 105, UpdateFields = 4, SaveUpdateFields = : System resource exceeded.

Any suggestions?
thanks, 73
ed

+ AA6YQ comments below

I updated as of your instructions but the french callbook does not work, at least not for me.
The web page seam to have changed name to nomenclature.r-e-f.org <http://nomenclature.r-e-f.org/> If I manually edit the F.txt and change all web references to this it works like a charm.

+Thanks Björn. Unfortunately, web-based sources of QSL information are occasionally relocated without warning.

+ Please attach your updated F.txt file to an email message and send it to me via

aa6yq (at) ambersoft.com

+ so that I can distribute it to the DXLab user community.

73,

Dave, AA6YQ

Bjorn and the group,

I've just tried modifying the French callbook lookup, and cannot get it to work with your link.
I have put the following into the F.txt file:
{SearchName}F Callbook
{SearchURL}http://nomenclature.r-e-f.org/
{SearchPostData}rtype=IND&req={TargetCallsign}
{SearchHeaders}Content-Type: application/x-www-form-urlencoded{13}{10}Host: nomenclature.r-e-f.org/{13}{10}Referer: http://nomenclature.r-e-f.org/{13}{10}
{SearchCaption}F CB
{SearchTooltip}click to search the French Callbook

Clearly, I have something wrong in there, and I am suspecting it will be in the SearchPostData or SearchHeaders lines.

Any ideas?

Dave AA6YQ, I modified the VK callbook, and that now works fine - thanks for the new link.

73 de Phil GU0SUP

I updated as of your instructions but the french callbook does not work, at least not for me.
The web page seam to have changed name to nomenclature.r-e-f.org
If I manually edit the F.txt and change all web references to this it works like a charm.
Regards
--
Björn, SM0SBL

+ AA6YQ comments below

Regarding my use of the words, "data leak," in Windows 10. I saw those in previous correspondence and repeated it below. I am sorry if I propagated an error.

I have rolled back to DXKeeper 15.9.9 and recovered my last backed up log. Everything seems to be complete and operating properly.


* Do you want me to send you my DXKeeper 15.9.9 log to you?


* Or do you want me to try the upgrade again and send you the log and an Error-Log at that time? That's assuming the error is repeatable.

+ As I previously posted, please place your log file in a zip archive, attach the zip archive to an email message, and send it to me via

aa6yq (at) ambersoft.com


I believe I have heard you say that DXKeeper can manage logs with hundreds of thousands of QSO's in the database. I neglected to ask the following:

* Is there a log size which I should not exceed?

+ I have a test log containing 1 million QSOs that DXKeeper has no trouble managing - including expanding its Mode item capacity from 8 to 12 characters. If you get to half a million QSOs in your log file, let me know and I'll start testing with a 2 million QSO log.

73,

Dave, AA6YQ

My comments below are not entirely correct.   When I open my log, it now complains about the data-width of multiple PSK modes.  This happens with DXKeeper 15.9.9 and my recovered  log which was backed up before I even downloaded the update/upgrade.  Each box must be cleared by clicking "OK."   After that everything seems to be great.

Again, thanks for your patience.

73,    Jerry

Dave,

Regarding my use of the words, "data leak," in Windows 10.   I saw those in previous correspondence and repeated it below.  I am sorry if I propagated an error.

I have rolled back to DXKeeper 15.9.9 and recovered my last backed up log.  Everything seems to be complete and operating properly.

• Do you want me to send you my DXKeeper 15.9.9 log to you?
  
  
• Or do you want me to try the upgrade again and send you the log and an Error-Log at that time?   That's assuming the error is repeatable.
  

I believe I have heard you say that DXKeeper can manage logs with hundreds of thousands of QSO's in the database.  I neglected to ask the following:

• Is there a log size which I should not exceed?

I also believe this is the first time that I have encountered a problem upgrading in my many years of using DXKeeper.  TU AGN.

73,        Jerry    K7VIT

# More AA6YQ comments below

+ ARRL staff are investigating the apparently longer "initial download" times from LoTW, but I suspect that Windows timing out before the initial download is complete may be the root cause

# I assembled errorlog.txt file entries submitted by 4 different DXLab users so that ARRL staff can compare them with LoTW event logs. In each case, the "invalid request" response appeared within 2 seconds of DXKeeper sending the download request to LoTW. My suspicion stated above that the root cause is a Windows timeout is thus unlikely to be correct.

# Not long ago, changes were made to the way LoTW handles download requests; one of these changes may be responsible for the occasional failures now being encountered. 

        73,

              Dave, AA6YQ

 

 

+ AA6YQ comments below

Due to time conflicts, I have been behind the curve on DXKeeper updates. 

I was running 15.9.9 and wanted to update to DXKeeper 16.1.5.  I do reboot my PC every day.  DXKeeper was the only app running, although I may have run DXView and Pathfinder earlier during the day's session before closing them both.  

Upon upgrading, I believe I experienced the data leak problem.   My K7VIT.mdb log contains just under 67,000 QSO's while my 3.60 GHz PC running Windows 10 has 32 GB of RAM.   The log wouldn't open and appeared corrupted ... at least it did in my almost panic stricken state.  Drawing on Dave's guidance, I rolled back to DXKeeper 15.9.9.  I also recovered my recently backed up log.   My PC perhaps was still "leaking" data because it wouldn't open the backed up log.   It was late and I needed a break.

Today after a reboot and making absolutely sure that I actually did a roll back to DXKeeper 15.9.9, I retried opening my log.  Whew!   All appears to be good so far in 7-land because my log comes up and it seems to be in tact. 

• My question is should I attempt to upgrade directly to DXKeeper 16.1.5?

• Or should I do an interim update such as upgrading to DXKeeper 16.1.0 before upgrading all the way to DXKeeper 16.1.5?

Thank you for your assistance, your patience, and thank you for these wonderful tools which help with our fantastic hobby

+ There is no "data leak" problem. 

+ Versions of DXKeeper from 16.1.0 onward will attempt to expand the capacity of  your log's Mode item from 8 characters to 12 characters, because ADIF recently approved the addition of several new modes with names longer than 8 characters; if I recall correctly, these new modes were defined by the author of FLDigi.

+ The "expand an item's capacity" mechanism in DXKeeper has been used on ~25 separate occasions since DXKeeper was first publicly released. For reasons I cannot yet identify, 10-15 users have reported that DXKeeper cannot upgrade their logs; in each case, Windows objects with an "insufficient system resources" error message. So far, I've been able to upgrade each of these logs by simply opening them with the current version of DXKeeper.  

+ Please place your log file in a zip archive, attach the zip archive to an email message, and send it to me via 

aa6yq (at) ambersoft.com

          73,

               Dave, AA6YQ

 

Hi Dave and all,

Due to time conflicts, I have been behind the curve on DXKeeper updates. 

I was running 15.9.9 and wanted to update to DXKeeper 16.1.5.  I do reboot my PC every day.  DXKeeper was the only app running, although I may have run DXView and Pathfinder earlier during the day's session before closing them both.  

Upon upgrading, I believe I experienced the data leak problem.   My K7VIT.mdb log contains just under 67,000 QSO's while my 3.60 GHz PC running Windows 10 has 32 GB of RAM.   The log wouldn't open and appeared corrupted ... at least it did in my almost panic stricken state.  Drawing on Dave's guidance, I rolled back to DXKeeper 15.9.9.  I also recovered my recently backed up log.   My PC perhaps was still "leaking" data because it wouldn't open the backed up log.   It was late and I needed a break.

Today after a reboot and making absolutely sure that I actually did a roll back to DXKeeper 15.9.9, I retried opening my log.  Whew!   All appears to be good so far in 7-land because my log comes up and it seems to be in tact. 

• My question is should I attempt to upgrade directly to DXKeeper 16.1.5?

• Or should I do an interim update such as upgrading to DXKeeper 16.1.0 before upgrading all the way to DXKeeper 16.1.5?

Thank you for your assistance, your patience, and thank you for these wonderful tools which help with our fantastic hobby.

73,        Jerry    K7VIT