View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003558||3 - Current Dev List||Bug||public||2019-11-08 09:42||2019-11-16 16:51|
|Platform||OS||Windows 10||OS Version||1903|
|Target Version||Fixed in Version||184.108.40.206|
|Summary||0003558: eQSL Download function loads all QSOs from eQSL server|
|Description||Dowloading eQSLs from eQSL server does not recognise "since" date but downloads all eQSLs since beginning of account.|
This can be several hundred QSOs
|Steps To Reproduce||With Logbook open go to:|
Select a recent "since" date
Click "Download from eQSL"
see large number of QSOs downloaded.
Repeat above steps
See same QSOs downloaded again
|Additional Information||Also being reported on Peer Support Forum|
As far as I can tell, the code is behaving correctly. There haven't been any recent changes in this area in HRD.
The API docs for eqsl.cc are here: http://www.eqsl.cc/qslcard/DownloadInBox.txt
The docs explain a format for the URL. One possible parameter for the download URL is RcvdSince. If a date of 2019-09-15 is used in the eqsl download dialog box, the program correctly (per the eqsl docs, anyway) prepares this URL:
The URL request results in an HTML page response which contains a link to an ADI file (along with a TXT file, too). HRD downloads that ADI file, parses it, and presents the results.
The docs say that RcvdSince sets a date for "everything that was entered into the database on or after this date", which means that a QSO record might appear in the download even if the QSO date is before the RcvdSince date. If the QSO record was added to the database after the date given in RcvdSince, then it's included in the download.
This is verifiable manually; just plug in your username and password to the above URL format and visit the resulting URL in your browser. When I do this with my account and 20190915, it works as I expect: a few "make up" QSOs appear, even though the QSO date is before 20190915 because they were entered to the database in October 2019. I have about 4500 QSOs at eqsl, and only 80-some are being downloaded with this request so I think the description that all QSOs are being downloaded is inaccurate and there's not a bug here.
The documentation says that LimitDateLo and LimitDateHi parameters are available; they have slightly different date formatting, but the real difference is their meaning: LimitDateLo is "the earliest QSO date to download". If there's interest, we can make the application have another date in the dialog box and let the user specify LimitDateLo, RcvdSince, or both, at their desire. We could add a third date control for LimitDateHi, if needed, too.
But as far as I can tell, the code is behaving as designed.
||Going off of the feedback from another issue, this isn't working. Probably one of these is a duplicate... but on the surface, I can't tell.|
I confirm the issue. Despite putting the Start date to 01/11/2019, eQSLs from 1966 were downloaded.
There is no way to halt the download.
Okay... here's exactly what's wrong.
eQSL-MysteryRevealed.png (305,438 bytes)
||Yes, I saw "John" for the Date.|
||This bug is for anyone that has to use a nickname, so probably why not everyone is seeing it. There also seems to be a bug with saving the password that I am looking at.|
Good point, Doug.
To further the explanation...
There are two aspects of "stations" within eQSL - nickname (that describes a location) and date range.
If you've only ever had one location... a nickname is irrelevant. So if you leave it out (and the nickname variable isn't required), then you just get the QSOs based on the date range.
It's only when people have multiple locations (nicknames), and in-particular during the same timeframe, is when you have a problem.
That said... this bug is one where the date was not being sent correctly and that's the cause of the problem.
||I am still seeing this in .245|
||checked in fix, will put a build together later tonight. Could not reproduce the password bug I saw, might be just a side effect of how I was testing it.|
||in the build just posted|
||I validated that Doug's fix corrected the bug. I'm leaving this open for other comments.|
||Validated in the 220.127.116.11 alpha|
|2019-11-08 09:42||g3ypp||New Issue|
|2019-11-10 13:48||K7ZCZ||Relationship added||has duplicate 0003566|
|2019-11-10 14:33||K7ZCZ||Assigned To||=> K7ZCZ|
|2019-11-10 14:33||K7ZCZ||Status||new => resolved|
|2019-11-10 14:33||K7ZCZ||Resolution||open => unable to reproduce|
|2019-11-10 14:33||K7ZCZ||Note Added: 0009228|
|2019-11-10 14:39||K7ZCZ||Relationship added||related to 0003571|
|2019-11-10 14:39||K7ZCZ||Relationship added||related to 0003570|
|2019-11-10 15:42||WA9PIE||Tag Attached: 6.7 defects|
|2019-11-10 15:56||WA9PIE||Project||2 - Next Dev List (Holding Area) => 3 - Current Dev List|
|2019-11-10 23:15||WA9PIE||Fixed in Version||=> 18.104.22.168|
|2019-11-11 15:41||WA9PIE||Status||resolved => assigned|
|2019-11-11 15:41||WA9PIE||Resolution||unable to reproduce => reopened|
|2019-11-11 15:41||WA9PIE||Note Added: 0009266|
|2019-11-12 03:41||g3ucq||Note Added: 0009275|
|2019-11-12 08:31||WA9PIE||File Added: eQSL-MysteryRevealed.png|
|2019-11-12 08:31||WA9PIE||Note Added: 0009284|
|2019-11-12 09:14||g3ucq||Note Added: 0009286|
|2019-11-13 01:16||DOUG||Assigned To||K7ZCZ => DOUG|
|2019-11-13 01:19||DOUG||Note Added: 0009291|
|2019-11-13 01:29||WA9PIE||Note Added: 0009292|
|2019-11-13 09:29||g3ypp||Note Added: 0009299|
|2019-11-13 22:22||DOUG||Note Added: 0009301|
|2019-11-14 00:30||DOUG||Assigned To||DOUG => WA9PIE|
|2019-11-14 00:30||DOUG||Status||assigned => resolved|
|2019-11-14 00:30||DOUG||Resolution||reopened => fixed|
|2019-11-14 00:30||DOUG||Note Added: 0009306|
|2019-11-14 02:50||WA9PIE||Fixed in Version||22.214.171.124 => 126.96.36.199|
|2019-11-14 02:50||WA9PIE||Testing||Not Started => Beta Successful|
|2019-11-14 02:50||WA9PIE||Note Added: 0009309|
|2019-11-16 16:51||WA9PIE||Status||resolved => closed|
|2019-11-16 16:51||WA9PIE||Testing||Beta Successful => Alpha Successful|
|2019-11-16 16:51||WA9PIE||Note Added: 0009337|