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

[IK5ZUK Luigi]

Hi Dirk, hi all.

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 ?

Thank you !

73 Luigi IK5ZUK

Luigi - IK5ZUK
Qth: Pisa
Locator: JN53FQ
Mail: ik5zuk at tiscali.it

Il 21/06/2020 23.27, Dirk Koopman via Dxspider-support ha scritto:
>
> 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
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20200621/5a4e65fb/attachment.htm>