<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Dirk, hi all.<br>
    <br>
    About 'convert-users-v3-to-v4.pl' it is menctioned as "an action
    needed to go from mojo build 228 and below" into the UPGRADE.mojo
    file: so for any build of dxspider regardless of branch below build
    229, running the command '/spider/perl/convert-users-v3-to-v4.pl' is
    not required anymore ?<br>
    <br>
    Thank you !<br>
    <br>
    73 Luigi IK5ZUK<br>
    <br>
    <pre class="moz-signature" cols="72">Luigi - IK5ZUK
Qth: Pisa
Locator: JN53FQ
Mail: ik5zuk at tiscali.it</pre>
    <div class="moz-cite-prefix">Il 21/06/2020 23.27, Dirk Koopman via
      Dxspider-support ha scritto:<br>
    </div>
    <blockquote type="cite"
      cite="mid:76f9bc21-ba87-4cd1-e3c7-ef9dc807148b@tobit.co.uk">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div class="moz-cite-prefix"><br>
        On 21/06/2020 21:25, Alex via Dxspider-support wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:000001d6480a$18087a90$48196fb0$@gmail.com">
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:EN-US">However
            I ran "git checkout mojo" and with<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:EN-US">  git
            branch i see again<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:EN-US"> 
             master<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:EN-US">* mojo<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:EN-US">with out
            newsusers<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:EN-US">How come
            I don't even see     newusers     on the list?<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:EN-US">What did
            I do wrong?<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
      </blockquote>
      <br>
      I have looked at the history (gitk --all) and  I think that I
      understand why there is a 'convert-users-v3-to-v4.pl' in this
      branch, but it should not do anything that would affect a 'mojo'
      branch version of  the code or affect the node in any way. The
      'mojo' branch code doesn't access the users.v4 file. What is more
      likely is that you have been struck by a Storable corruption -
      which I am now seeing much more on RPi nodes - as the SD Cards
      that most people use wear out after six months or so. <br>
      <br>
      Fairly soon, I am going to do a users file change. That code is
      rather better tested and reliable - unlike the experimental
      "newusers" branch which attempted to remove DB_File as well as
      Storable. As soon as I am happy with and issued the RBN code, I
      shall be merging the new version of the users file (users.v3j)
      which is exactly the same format and usage as users.v3 but using
      JSON instead of Storable as the serialisation code.<br>
      <br>
      To explain: it is not possible to store the (binary) internal user
      records directly to disk, they have to be "serialised" (or
      "frozen") before they are stored. To access a user record, I get
      it from the disk and then "unserialiase" (or thaw) it before I can
      use it in code. Up until recently, this was done by the standard
      perl module Storable, but it has caused a number of errors over
      the years and is unusably unreliable with subcommands (commands
      that run in forked copies of the node - like sh/dx).<br>
      <br>
      But I will merge that work when I am satisfied that the RBN code
      is stable enough for general testing. <br>
      <br>
      If anyone is interested to see the work in progress, login to
      gb7djk.dxcluster.net 7300 and do a 'set/wantrbn'. You are advised
      to also do an:<br>
      <br>
        accept/rbn by_zone 14 and not zone 14 or zone 14 and not by_zone
      14<br>
      <br>
      replacing the '14' with your cq zone. This will a) cut down on the
      spots that you receive and b) only show you spots where the
      skimmer or spotted call is in your zone and the other is not. No
      spots from the skimmers for calls in the same zone :-) <br>
      <br>
      In the info you might see something like:<br>
      <br>
      <tt>CW  24dB Q:8*+ Z:14,15</tt><tt> </tt><tt><br>
      </tt><tt>           ^^^</tt><tt><br>
      </tt><tt>           ||+-- Respotted - means that it has been seen
        for at least one hour and is a repeat (once / hour)<br>
                   |+--- * means that the skimmer could not agree on the
        frequency, the one shown is the majority opinion.<br>
                   |     This is distressingly common. I have seen
        discrepancies of 600Hz! <br>
                   +---- The "quality" 1-9. This is count of skimmers
        (max 9) that have spotted this call. If this is > 1 then the<br>
                         spot call is likely not to be "busted".<br>
        <br>
        The Z:14:15 is a list of cq zones that the spotting skimmers are
        in. If you have no filters then this list does not include the
        skimmer on the spot. Also, again if you don't have filters, then
        skimmer call and the dB figure is the lowest one seen (if Q:
        > 1). If you do have a filter then the spot shown will be the
        most "relevant" one. <br>
        <br>
        73 Dirk G1TLH<br>
      </tt> <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Dxspider-support mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dxspider-support@tobit.co.uk">Dxspider-support@tobit.co.uk</a>
<a class="moz-txt-link-freetext" href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>