[Dxspider-support] Respotting defects?

[djk]

I am actually working on this area of the code at the moment in an 
effort to prevent the situation where certain stations send the same 
spot - at the same time - to as many nodes as possible.

Some time ago I asked the question as to whether I can remove the 
originating node from the spot dupe code. I am not aware of anybody 
giving me a definitive answer so I am going to default to remove the 
originating node.

There are some other twiddle pots in the code which I have put in over 
the years, some of which could (and in a few cases) should be revisited.

Having said that - even in the current mojo branch code - changing the 
"spotter" will (in my tests at least) be treated as a new spot. In fact, 
whilst I was doing this earlier today, I noticed two spots for the same 
Danish beacon (and time) come in, one after the other, from different 
spotters and they appeared in my console as one would expect.

DXSpider does not limit spotting the same callsign by different spotters 
either at the same time or later. It does, however, stop the same user 
spotting the same callsign on the same QRG and comment (if any). The 
only time this is allowed is with some (extra) information in the 
comment section.

This is the tuple that is stored in the spot cache: 
"X|$call|$by|$qrg|$node|$nd|$text"

$qrg is "slot" of frequency which has been too large, I will reduce this 
to (default) 25Khz - but I am open to discussions about this. Change 
$Spot::qrggranularity.

$nd  is "slot " of time. This may be overkill but is (default) 10 
minutes (600 seconds). Change $Spot::timegranularity.

A stored dupe tuple like this is only active for (default) 1 hour (3600 
secs) . Change $Spot::dupage.

In my test code currently running on GB7DJK the $node field is blanked 
out and the $qrg field is normalised to the nearest 25Khz.

Until this email, I have not had any complaints from sysops about 
excessively strict deduping. So am at a loss to explain why you have 
these problems.

73 Dirk G1TLH

On 18/06/2024 13:09, Björn Ekelund via Dxspider-support wrote:
> This morning I was verifying some changes in the spot handling 
> functionality
> in DXLog and doing this I created manual spots on my DXSpider node.
>
> When spotting a callsign again on the same frequency after a few minutes,
> DXSpider told me "Sorry, this is a duplicate." Which is sort of expected.
>
> What was *not *expected is that DXSpider kept saying this also after 
> over 30 minutes,
> even when spotting using a different callsign. This is unacceptable.
> If limiting repeat spots on the same frequency at all, the timer 
> should not be longer
> than RBN which is 10 minutes.
>
> What was *also not *expected is that it did not matter if I 
> changed the frequency
> of the spot. Spotting the callsign on a completely new frequency 
> within the same band
> yielded the same message about being a duplicate. This is clearly a 
> bug. When a
> station is spotted on a new frequency, no re-spotting rules should apply.
>
> Björn SM7IUN
>
>
> _______________________________________________
> 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/20240618/b8826ecf/attachment.htm>