[Dxspider-support] R: R: I: Problem shutdown dxspider?

[Dirk Koopman]

On 21/06/2020 21:25, Alex via Dxspider-support wrote:
>
> However I ran "git checkout mojo" and with
>
>   git branch i see again
>
>    master
>
> * mojo
>
> with out newsusers
>
> How come I don't even see     newusers     on the list?
>
> What did I do wrong?
>

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.

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.

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).

But I will merge that work when I am satisfied that the RBN code is 
stable enough for general testing.

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:

   accept/rbn by_zone 14 and not zone 14 or zone 14 and not by_zone 14

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 :-)

In the info you might see something like:

CW  24dB Q:8*+ Z:14,15
            ^^^
            ||+-- Respotted - means that it has been seen for at least 
one hour and is a repeat (once / hour)
            |+--- * means that the skimmer could not agree on the 
frequency, the one shown is the majority opinion.
            |     This is distressingly common. I have seen 
discrepancies of 600Hz!
            +---- The "quality" 1-9. This is count of skimmers (max 9) 
that have spotted this call. If this is > 1 then the
                  spot call is likely not to be "busted".

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.

73 Dirk G1TLH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20200621/581b8fb5/attachment.htm>