Cluster Bug

[K5CKS]

I just discovered this problem this morning... I wanted to know the last time JX2US was spotted so I opened the cluster window and sent the command sh/dx jx2us. It showed the last several dates and times he was spotted so I closed the window. On the cluster screen on the main Log4OM window it showed JX2US as being spotted on several bands TODAY. Clearly wrong. It looks like the correct times for the spots were brought over into the cluster window but the correct dates were not. Please see the attachment.
73,
Rory, K5CKS

[KI5IO]

I just discovered this problem this morning... I wanted to know the last time JX2US was spotted so I opened the cluster window and sent the command sh/dx jx2us. It showed the last several dates and times he was spotted so I closed the window. On the cluster screen on the main Log4OM window it showed JX2US as being spotted on several bands TODAY. Clearly wrong. It looks like the correct times for the spots were brought over into the cluster window but the correct dates were not. Please see the attachment.
73,
Rory, K5CKS

Rory,

I did the same commands you noted and was in the Cluster Management tab of the Telnet Cluster on V2. I got the historical data for jx2us (from 25 November to 29 November), but it did not transfer to my Cluster tab or the F8 Cluster tab.

I use clusters from ve7cc and n4zkf. Both can have filters set via CC User.

I just did a second test of this issue using V 2.10.0.0 and DID replicate what you found.

I'm currently testing Alpha Release V 2.10.0.4 and (as I noted above with my first test) the issue is gone or repaired.

An updated version of Log4OM V2 is not too far from release

Thanks for bringing this issue to our attention.

.

[IW3HMH]

Hi Rory, that's because when you "ask" for previous spots, the cluster effectively sends them to you...
you can see them, but Log4OM cannot distinguish them from "normal spots", so it parses them like normal spots.
I must check if those rows contains something different and can be identified...
Typically the SPOT DATE is available in the cluster data, but we experienced troubles with clusters that weren't correctly aligned to UTC, in the UTC midnight area, that could transmit an actual spot with a different date (one day ahead/one day behind) so we don't applied any "check" to this info.

We can eventually add a 30' check from PC current UTC date/time but will not be resolutive, as some clusters reports spot in the form of:

DX de ...

And those spots DOESN'T CONTAINS any info about DATE of the spot, they contains only TIME, so a spot of 2 months ago made in the same time frame of the current time may be considered as "good and actual"

[K5CKS]

Thank you for the fast reply... the cluster I am using does show the date and time of the spot. I was concerned that Log4OM didn't carry the date data through to the cluster window. I am sure you will figure this out. I love Log4OM, there is no better DX logging software out there for any price.
73,
Rory, K5CKS