<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">Dirk,</div><div dir="ltr"><br></div><div dir="ltr">Not a complaint, just a question as you review the deduping code: would you consider adding the feature of a preferred spotter where spots from such spotters always go out and are never subject to any filters? This would be a per user rather than per cluster setting.</div><div dir="ltr"><br></div><div dir="ltr">The actual use case is N1MM’s preferred spotter feature that is seriously crippled down because upstream clusters dedupe and preferred spots are far and between. I’ve been looking at solutions that consolidate multiple telnet streams, but they all have the same limitation- they can feed the logger spots, but can’t take spots from the logger.</div><div dir="ltr"><br></div><div dir="ltr">Thanks for considering it!</div><div dir="ltr"><br></div><div dir="ltr">Rudy N2WQ</div><div dir="ltr"><br id="lineBreakAtBeginningOfSignature"><div dir="ltr"><div><span style="background-color: rgba(255, 255, 255, 0);">Sent using a tiny keyboard. Please excuse brevity, typos, or inappropriate autocorrect.</span></div><div><br></div></div><div dir="ltr"><br><blockquote type="cite">On Jun 18, 2024, at 2:59 PM, djk via Dxspider-support <dxspider-support@tobit.co.uk> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>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. <br>
</p>
<p>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. <br>
</p>
<p>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. <br>
</p>
<p>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. <br>
</p>
<p>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. </p>
<p>This is the tuple that is stored in the spot cache:
"X|$call|$by|$qrg|$node|$nd|$text" <br>
</p>
<p>$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.<br>
</p>
<p>$nd is "slot " of time. This may be overkill but is (default) 10
minutes (600 seconds). Change $Spot::timegranularity.<br>
</p>
<p>A stored dupe tuple like this is only active for (default) 1 hour
(3600 secs) . Change $Spot::dupage.<br>
</p>
<p>In my test code currently running on GB7DJK the $node field is
blanked out and the $qrg field is normalised to the nearest 25Khz.
<br>
</p>
<p>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. <br>
</p>
<p>73 Dirk G1TLH<br>
</p>
<div class="moz-cite-prefix">On 18/06/2024 13:09, Björn Ekelund via
Dxspider-support wrote:<br>
</div>
<blockquote type="cite" cite="mid:CABmD_KRsS4ufLc+veiwwTSJc-DD5STA_1L8JOTVyDMqSgQS4Lw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">This morning I was verifying some changes in the
spot handling functionality
<div>in DXLog and doing this I created manual spots on my
DXSpider node.
<div><br>
</div>
<div>When spotting a callsign again on the same frequency
after a few minutes, </div>
<div>DXSpider told me "Sorry, this is a duplicate." Which is
sort of expected.</div>
<div><br>
What was <b>not </b>expected is that DXSpider kept saying
this also after over 30 minutes, </div>
<div>even when spotting using a different callsign. This is
unacceptable.</div>
<div>If limiting repeat spots on the same frequency at all,
the timer should not be longer </div>
<div>than RBN which is 10 minutes.</div>
<div><br>
</div>
<div>What was <b>also not </b>expected is that it did not
matter if I changed the frequency </div>
<div>of the spot. Spotting the callsign on a completely new
frequency within the same band </div>
<div>yielded the same message about being a duplicate. This is
clearly a bug. When a </div>
<div>station is spotted on a new frequency, no re-spotting
rules should apply.</div>
<div><br>
</div>
</div>
<div>Björn SM7IUN</div>
<div><br>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Dxspider-support mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" 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>
<span>_______________________________________________</span><br><span>Dxspider-support mailing list</span><br><span>Dxspider-support@tobit.co.uk</span><br><span>https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</span><br></div></blockquote></div></body></html>