Loading ...
Sorry, an error occurred while loading the content.

RE: [ARRL-LOTW] "Trusted QSL" version 1.14 is available for beta testing

Expand Messages
  • Gary Hinson
    “… if a .tq8 is signed and lost before upload, we will consider it a duplicate the next time around …” If (when!) that happens, is there an option to
    Message 1 of 107 , Apr 5 4:25 PM
    • 0 Attachment

      “… if a .tq8 is signed and lost before upload, we will consider it a duplicate the next time around …”

       

      If (when!) that happens, is there an option to force a re-send, temporarily disabling the dupe-check?

       

      73

      Gary  ZL2iFB

       

       

       

      From: ARRL-LOTW@yahoogroups.com [mailto:ARRL-LOTW@yahoogroups.com] On Behalf Of Robert KC2YWE
      Sent: Saturday, 6 April 2013 9:55 a.m.
      To: ARRL-LOTW@yahoogroups.com
      Subject: Re: [ARRL-LOTW] "Trusted QSL" version 1.14 is available for beta testing

       




      On 4/5/2013 9:28 AM, Larry Banks wrote:

       

      I guess I misunderstood the scenario.   Are you saying that there might not be dupes in the file -- just that the logger itself is not fully compliant?  If so, I will think about a better wording.  However, why show this error message if there are no dupes in the file?  Why not show it only when there are dupes?  (I would assume that this is because the script has not yet looked for dupes?)


      - First of all, the duplicate checker will not flag anything other than *exact* duplicates. Same certificate, call, times, frequencies, modes, etc. Near duplicates (fixed station location, different certificate) are not counted. It doesn't make mistakes. If a QSO in the database actually made it to LoTW, there is never a reason to re-upload it - of course, if a .tq8 is signed and lost before upload, we will consider it a duplicate the next time around because the assumption ("file was uploaded and is in LoTW") is wrong. If you use the "sign and upload" functionality, either via the interface or via the command line, we do not enter the QSOs into the database unless the server said "accepted" - network or server problems will not cause duplicates the next time around.

      - The popup only shows if there's dupes. It's the same popup as you get if you sign a dupe-containing file by hand via the TQSL interface, with the same options

      - It only has the additional "upgrade your logger" text if the command line doesn't include the '-a' flag with an option that either tells TQSL how to answer that popup (in which case you won't see it), or that it's safe for the user to pick any choice ('-a ask'), in which case the "upgrade your logger" text doesn't show because the program has said that all options are safe.

      - We don't mean to imply that a logger is broken for not including the flag - it's new this version. We also don't mean to imply that the logger has done something bad by sending duplicates - the duplicate-checking code is there to deal with this. But all choices on that dialog will confuse some loggers - 'cancel' will confuse loggers that (incorrectly) don't check the output of TQSL to see if it signed anything, 'strip duplicates' will confuse (a very few) loggers that make some assumption about resubmitting duplicates, and 'allow duplicates' is bad for the whole system and additionally sets a flag in the upload telling LoTW that it may process that upload at a lower priority since it is known to have duplicates (this isn't implemented yet, nor are there any plans, but it is possible with this flag).

      - In general, 'strip duplicates' is safe. Consider a logger that feeds A-Z QSOs to TQSL for signing. If A-M are already in LoTW, and duplicates are stripped, then the upload will only contain N-Z. If the logger either doesn't track "LoTW sent" or tracks it as a simple checkbox, everything is perfect - A-Z will be checked as "LoTW sent"; even if they weren't in that specific batch, they *were* sent to LoTW.

      - The only time 'strip duplicates' will cause unexpected behavior is for a particularly clever logger that does its own duplicate handling and knows if you resend a QSO - and so doing causes it to be marked as "re-sent" or something similar. Dave AA6YQ brought this problem to our attention with DXKeeper - it makes the assumption that all QSOs handed to TQSL for signing are in the output, and expects to find them in that particular batch when the next "sync" happens. Most loggers aren't so sophisticated, and don't have problems with stripping duplicates.

      Hopefully this helps explain what's going on. It's a hard thing to describe tersely enough that people might read it in a popup, and I struggled with that wording for hours. If you have alternate wordings, or just suggestions on how better to phrase it, I'm all ears.

      73,
      -Robert, KC2YWE




      --
      This message has been scanned for viruses and
      dangerous content by MailScanner, and is
      believed to be clean.
    • Gary AL9A
      Thanks Robert. TQSL V1.14 now reinstalled and a new tq8 file just uploaded. Will check the status in the morning. 73, Gary AL9A ... From: Robert KC2YWE To:
      Message 107 of 107 , Apr 7 10:38 PM
      • 0 Attachment
        Thanks Robert.  TQSL V1.14 now reinstalled and a new tq8 file just uploaded.  Will check the status in the morning.
         
        73,
        Gary AL9A
         
        ----- Original Message -----
        Sent: April 07, 2013 8:18 PM
        Subject: Re: [ARRL-LOTW] "Trusted QSL" version 1.14 is available for beta testing

         

        On 4/8/2013 12:07 AM, Gary AL9A wrote:
        Oh boy, this is getting to be even more fun.  Went to Unistall and got this error message.  "C:\Program Files\TrustedQSL\unins000.dat does not exist.  Cannot uninstall."

        So really briefly, the problem is that when you did a "last known good" setting, it restored a registry backup. But that doesn't touch the files, so I think the files and the registry information pointing to them is just out of agreement.

        As a simple fix, go into C:\Program Files\TrustedQSL and delete everything in there. It's OK - your certificates and locations are stored somewhere else (we won't touch that). Then the 1.14 installer should run fine. The problem is that it's trying to run the uninstaller for 1.13, but it's failing (as you see when you do it manually) and so the installer gives up. If you delete all the files, it won't think it's installed and it should install normally. Afterwards, you should be able to uninstall and install it normally.

        73,
        -Robert, KC2YWE

      Your message has been successfully submitted and would be delivered to recipients shortly.