View Issue Details

IDProjectCategoryView StatusLast Update
00035583 - Current Dev ListBugpublic2019-11-16 16:51
Reporterg3yppAssigned ToWA9PIE 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformOSWindows 10OS Version1903
Product Version 
Target VersionFixed in Version6.7.0.247 
Summary0003558: eQSL Download function loads all QSOs from eQSL server
DescriptionDowloading 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 ReproduceWith Logbook open go to:
More>eQSL.cc>Download
Select a recent "since" date
Click "Download from eQSL"
see large number of QSOs downloaded.
Repeat above steps
See same QSOs downloaded again
Additional InformationAlso being reported on Peer Support Forum
Tags6.7 defects
ModuleLogbook
Sub-ModuleeQSL
Testing Alpha Successful

Relationships

has duplicate 0003566 resolvedWA9PIE eQSL.cc download is not honoring the date in the download dialog box 
related to 0003571 closedWA9PIE eQSL QSO download doesn't correctly parse result URL from response 
related to 0003570 closedK7ZCZ eQSL download requests are over HTTP not HTTPS 

Activities

K7ZCZ

2019-11-10 14:33

administrator   ~0009228

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:

http://www.eqsl.cc/qslcard/DownloadInBox.cfm?UserName=CALL-SIGN-HERE&Password=PASSWORD_HERE&RcvdSince=20190915


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.

WA9PIE

2019-11-11 15:41

administrator   ~0009266

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.

g3ucq

2019-11-12 03:41

updater   ~0009275

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.

WA9PIE

2019-11-12 08:31

administrator   ~0009284

Okay... here's exactly what's wrong.

eQSL-MysteryRevealed.png (305,438 bytes)

g3ucq

2019-11-12 09:14

updater   ~0009286

Yes, I saw "John" for the Date.

DOUG

2019-11-13 01:19

developer   ~0009291

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.

WA9PIE

2019-11-13 01:29

administrator   ~0009292

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.

g3ypp

2019-11-13 09:29

updater   ~0009299

I am still seeing this in .245

DOUG

2019-11-13 22:22

developer   ~0009301

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.

DOUG

2019-11-14 00:30

developer   ~0009306

in the build just posted

WA9PIE

2019-11-14 02:50

administrator   ~0009309

I validated that Doug's fix corrected the bug. I'm leaving this open for other comments.

WA9PIE

2019-11-16 16:51

administrator   ~0009337

Validated in the 6.7.0.247 alpha

Issue History

Date Modified Username Field Change
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 => 6.7.0.245
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 6.7.0.245 => 6.7.0.247
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