View Issue Details

IDProjectCategoryView StatusLast Update
00034513 - Current Dev ListBugpublic2019-10-23 04:06
Reportern4fnAssigned Ton4fn 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionreopened 
Product Version 
Target VersionFixed in Version6.7.0.235 
Summary0003451: Operators name repeated on new contacts
Descriptionit appears that there may be a "bug" that may show up on some PC's (but not all): What is happening is using WSJT-X and FT8 and in SSB and CW modes I work a station and log it with his name in the name field. Every contact after that the same name shows up for the operator and I have to edit the contact with the correct name. I have a paid QRZ,com account and it shows in HRD. The funny thing is the first contact when I start HRD and log that one the name is correct, after that the same name appears as the operator continuously . I have contacted QRZ and they say it is in HRD . They were correct. At the suggestion from Bill I did the same on my non shack PC that is in a Demomatic mode, it did the same duplication of operator names. Frustrated I filed a support ticket and had a speedy email from Tim. Since it was a Beta version he was unable to assist. Taking a chance I went back to the last regular (non beta) version after deleting the beta on the demo PC. Voila! the duplication ceased. So then to the Shack PC and the same thing , all was normal and the correct names were displayed. I am not sure why it affected my two PC's but I will leave the solution to the wizards who are in the smart department.
Many thanks
Neil Foster N4FN
Steps To ReproduceVerified on 2 PC's and also by Tim Browning
TagsNo tags attached.
ModuleLogbook
Sub-Module(select)
TestingNot Started

Relationships

related to 0003432 closedPD9FER When doing lookups with same station worked before, RST is set to latest QSO RST 

Activities

KB3NPH

2019-09-23 13:06

administrator   ~0008610

I have been working to confirm this issue. The very first time you start HRD for a session, and make your first QSO, whether it be by voice or digital or WSJT-X with QSO Forwarding active, the very first contact logs properly in the Logbook. Each contact you enter after the first one will log with the proper callsign but ALL other information that was automatically added from QRZ to the very first contact will be logged every QSO after that. I've entered an image of three contacts I logged today. As you can see the callsign logged properly, but the name and, although I didn't show it in these images, all information from QRZ was the information from the very first QSO I logged.

PD9FER

2019-09-23 13:23

updater   ~0008611

I am unable to replicate

w4ase

2019-09-23 14:28

updater   ~0008619

Ok I know this may not be helpful.....but I can not duplicate this. However, I see from some of the comments others are having the problem. Windows 10 or Windows interface or old installs?

K7ZCZ

2019-09-24 19:32

administrator   ~0008639

Last edited: 2019-09-24 19:33

View 2 revisions

Please make a note of which build of the product is being used when observing this behaviour. This information is requisite to any investigation proceeding. Please also provide step-by-step repro instructions.

KB3NPH

2019-09-25 07:50

administrator   ~0008655

Sorry Mike, I missed that in Neil's initial report that the version wasn't included. It's with the 6.7.0.227 Beta build.

K7ZCZ

2019-09-25 08:40

administrator   ~0008659

Thanks. Are repro steps not available?

KB3NPH

2019-09-25 09:03

administrator   ~0008660

There are TWO threads in the Beta Testers forum about this issue.

Beta Testers forum.https://forums.hamradiodeluxe.com/node/51014#post51014

and the other is in https://forums.hamradiodeluxe.com/node/50980#post50980

K7ZCZ

2019-09-25 11:09

administrator   ~0008664

So no repro steps? If I have to guess my way through it, I can try -- but diagnosing problems is always easier when repro steps are available.

KB3NPH

2019-09-25 12:36

administrator   ~0008665

The steps to reproduce this issue are the very same steps that any one who uses the HRD software and the HRD Logbook would use to log the contacts he/she makes. Most don't even have to read the instruction manual.

On the desktop (that's the display on your computer's monitor that comes up when the Windows operating system has started) click on the Icon that has "Ham Radio Deluxe" under it. This will start the Ham Radio Deluxe Rig Control (providing your connected to a radio). If you don't have the Logbook configured to automatically start with Rig Control starts, on the Rig Control screen, click on the little button that says "Logbook" and your HRD Logbook should open. (This is where you have a bunch of lines that have data in them about the contacts (people you have talked to).

Step #1 Now that the logbook is open continue to Step #2.
Step #2 Make sure QRZ Lookup is setup. (Are exact steps needed for this)
Step #3 Open the ALE (It's the little button on the toolbar that has a green 'ball' with the letters "A" "d" "d" under it
Step #4 In the ALE, type in any callsign (That means a ham callsign) in the box marked "Call"
Step #5 Press the "TAB" key on your keyboard OR click on the little button to the right of the call field that is looks like this [Lookup]
Step #6 Wait for all the fields to be populated (Fields are all those other empty boxes in your ALE)
Step #7 After all the fields are populated, click on the little button in the lower left corner of the ALE that looks like this [Add (f7) OR click the F7 key on your computer keyboard.
Step #8 Notice that the information from the ALE was sent to the Logbook records

Once you are certain the information you just entered has been recorded in the Logbook, proceed.

Step #9 Open the ALE (It's the little button on the toolbar that has a green 'ball' with the letters "A" "d" "d" under it
Step #10 In the ALE, type in any callsign (That means a ham callsign) in the box marked "Call" [NOT THE SAME CALL AS IN STEP #4]
Step #11 Press the "TAB" key on your keyboard OR click on the little button to the right of the call field that is looks like this [Lookup]
Step #12 Wait for all the fields to be populated (Fields are all those other empty boxes in your ALE)
Step #13 After all the fields are populated, click on the little button in the lower left corner of the ALE that looks like this [Add (f7) OR click the F7 key on your computer keyboard.
Step #14 Notice that the information from the ALE was sent to the Logbook records [Notice the callsign is correct but all other info is the same as the previous record

If you need more steps to reproduce the issue described in this record, just start with Step#1 and continue through Step #14. Do this as many times as necessary to understand produce the issue which was shown in the attached images in the above Note: 0003451:0008660

w4ase

2019-09-25 12:49

viewer   ~0008666

:>) Very nice presentation Tim KB3NPH! I just love it!

You know I deal with a number of high priced coders in my company....I have one rule in the company with regard to them......never never never never let them talk to a customer or for that matter anyone else we don’t want to make mad!

KB3NPH

2019-09-25 12:57

administrator   ~0008667

Ticket #803567
Ronald posted 09/25/2019 12:54 PM
ALE window in 6.7.0.227 Beta ( Mike C sent me a copy to look at FT4 LOTW confirmation, which works!)

Almost too many to list that don't work in ALE window ALE window FUBAR

1) First lookup of a station fills some data for station
Things like country and previous comments are not populated
2) Lookup order not honored - if station is in logbook (first place to iook in my list) nothing is recovered
3) Lookup another station and data for first station (such as it is) shows ... Shut down ALE and restart to get new data - i.e."reset" does not reset
4) Since 'Country' does not populate, 'Worked" window does not show bands needed for that country

I did not see anything wrong with 'old' lookup scheme - One step forward and 5 steps backward

I posted this in here because I feel once the main cause of the initial report has been resolved, that will resolve the rest of the issues Ron reported.

g3ucq

2019-09-25 13:37

updater   ~0008668

I confirm what KB3NPH is reporting.

WA9PIE

2019-09-25 14:48

administrator   ~0008671

I know that the QRZ lookup has a problem because it’ doesn’t match the tech spec. We’ll sort it out before we release 6.7.

K7ZCZ

2019-09-26 09:18

administrator   ~0008697

@WA9PIE: If there's an issue with QRZ lookup, please open a separate Mantis issue for it with a specific description of the problem. At this moment, I don't think there are any QRZ-specific issues.

K7ZCZ

2019-09-26 09:29

administrator   ~0008699

Thanks for writing up the repro steps, Tim. Complete steps make investigating any issue much easier and faster, help document the issue fixed, and show testers what functionality needs to be verified before shipping the product.

I've checked in a fix for the issue you've described in this change set:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5169

While I know my change addresses the issue you describe, I'm worried because your repro steps don't match the original problem description given by N4FN here. He says the problem involves certain modes (CW and USB), but your repro steps make no mention of a specific mode. He says he is collecting QSOs from an external source (WSJTX), but your steps use the ALE directly. He says he's using "demomatic mode", which means Rig Control is involved, but your steps don't involve Rig Control.

Since we don't have specific details about N4FN's specific problem, how do you propose we decide if this Mantis issue should be resolved or not?

KB3NPH

2019-09-27 08:02

administrator   ~0008708

Mike, please note my entry: https://development.hamradiodeluxe.com/view.php?id=3451#c8610 where I confirmed N4FN's specific problem and noted that it pertained to entries QSO forwarded from WSJTX AND entries entered directly from the Logbook ALE. I also added a screenshot demonstrating the issue that was described by N4FN. To further provide documentation that the issue I described in my https://development.hamradiodeluxe.com/view.php?id=3451#c8610 note was the exact same issue reported by N4FN, I provided in my note: https://development.hamradiodeluxe.com/view_user_page.php?id=3 links to the Forum issues pertaining to this Mantis report. Both of these links are to posts in the Beta Testers Forum, which you are part of and check quite often. One of these links was the original thread that N4FN created about this particular issue and I, along with others, had also commented in that thread that we were experiencing the very same issue. Comments added by two or three other beta testers also confirmed the issue that N4FN had initially posted here.

It seems everyone is attempting to work with you and provide the information you need for not only this bug report, but many, many others, and yet you can say "Since we don't have specific details about N4FN's specific problem, how do you propose we decide if this Mantis issue should be resolved or not?"....... My response is, Mike, rest assured, the initial issue that N4FN reported, and all the following notes in this thread DO INDEED pertain to the VERY SAME PROBLEM, therefore, in response to your last question, YES this Mantis issue SHOULD be resolved. Now, all we need is a new beta release to test to see if your fix that was done in change set: https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/5169 did resolve this lookup issue. Thanks Mike.

K7ZCZ

2019-09-27 08:48

administrator   ~0008709

The note you reference, Tim, says "whether it be by voice or digital or WSJT-X with QSO Forwarding active". I don't see where it mentions manually entering a QSO with the ALE. Ferry and W4ASE subsequently said they couldn't reproduce the issue, either, so I don't think I'm alone in not being able to demonstrate the issue.

The forum posts I saw were just copies of what was posted here; some users repro it, some users can't. Another user noted different symptoms, but none of them provided enough context to pursue the investigation or implementation of a fix. Indeed, if each problem report we had in Mantis had repro steps as clear and specific as the ones you provided here, we'd be able to resolve issues much more accurately and efficiently.

If you know that the manual entry scenario that you describe mimic's N4FN's report, then that's great -- the issue is solved. Change 5169 was built into 6.7.0.231 yesterday. If MikeC decides to release it, then you can use it for testing.

K7ZCZ

2019-09-27 08:48

administrator   ~0008710

With a fix available, I'm marking this resolved.

KB3NPH

2019-10-02 16:15

administrator   ~0008733

Tested Alpha V 6.7.0.231 and found this issue was only partially resolved. To test I followed all the same procedures I entered in Note# 0008665.

Run HRD and open the HRD Logbook.

Step #1 Now that the logbook is open continue to Step #2.
Step #2 Make sure QRZ Lookup is setup. (Are exact steps needed for this)
Step #3 Open the ALE (It's the little button on the toolbar that has a green 'ball' with the letters "A" "d" "d" under it
Step #4 In the ALE, type in any callsign (That means a ham callsign) in the box marked "Call"
Step #5 Press the "TAB" key on your keyboard OR click on the little button to the right of the call field that is looks like this [Lookup]
Step #6 Wait for all the fields to be populated (Fields are all those other empty boxes in your ALE)
Step #7 After all the fields are populated, click on the little button in the lower left corner of the ALE that looks like this [Add (f7) OR click the F7 key on your computer keyboard.
Step #8 Notice that the information from the ALE was sent to the Logbook records

I created a graphic image and added it to this note.
In this image, not the following.

Box# 1 when I entered callsign PD9FER I clicked the "Lookup" button and it populated the ALE. As you can see, the arrow running from Box#1 to the Logbook record indicates that PD9FER was entered correctly in the logbook along with the correct name and RST/RAQ numbers.

Box# 2 shows the Locator, State, and QTH that was populated with the data from my last logging session which was on 9/27/2019 and was not updated correctly in this logging session after the lookup was clicked. You can follow the arrow from Box#2 to the "Location" tab in the ALE to see the incorrect data in there, and also the arrow from Box#2 to the logbook record which contains the improper data in this logged record.

This will probably be sent to another bug report but in my image I show box #3, which indicates that the Country field of the ALE is NOT being populated at all.

231 Alpha Test.jpg (282,373 bytes)

K7ZCZ

2019-10-04 08:56

administrator   ~0008741

Sorry, I'm not able to reproduce this behavior. My guess is that it's dependent on the callsign lookup configuration, and perhaps the state of the logbook database open when the lookup operation is performed. Please provide information on the callsign lookup configuration you've got in place when reproducing this issue. At the very least, please record which items are enabled, and in what order are they set.

If would be useful to know what entries were selected in the logfile view before the ALE was opened. The provided repro steps make no mention of this state.

It would be beneficial to have information about the behaviour of the issue relative to previous entries in the logbook -- why were my name and address information selected? Were they previously entered in this logbook? Previously used in a lookup operation? Where in the logbook do they appear? How do they relate to the ALE entry being added?

It would also help to collect information from the Logfile view. Before exercising the steps to reproduce the problem, follow these steps:

1) Use the "Logfile" command in the "View" menu
2) Mark the "Debug" button in the Logfile view.
3) Clear the logfile view with the "erase" button in the toolbar

After exercising the issue, return to the Logfile view:

1) Use the "Logfile" command in the "View" menu
2) Use the "Text View" button to open a copy of the entries in the logfile
3) attach them to the report.

KB3NPH

2019-10-05 07:52

administrator   ~0008749

It would appear this issue IS resolved. After reading the last comments I proceeded to retest. I tested it with on my normal test database which is an Access DB with about 11K of records. Tested with lookup options configured in QRZ > Logbook > Country List order. and got the same problem as reported earlier where the Callsign entered and the Name related to that call was correct but all other info was from a previously logged QSO. I then reversed the QRZ and Logbook in the lookup options to Logbook > QRZ > Country List. When testing this order I had the same issue as with the previous test.

I then worked via Teamviewer with Kevin and we ran a couple tests and could NOT reproduce the problem on his computer.

Taking Mike B's suggestion, I changed to another Access database which has about 90K of records. Ran the test of entering several contacts and all logged perfectly. Ran the same test with another Access database containing about 150K of records and all logging properly in that.

Next test was done on the air working a few FT8 contacts with WSJT-x and QSO Forwarding to my Maria SQL database. All logged as they should. Did same on the air test with my normal Access Database and the several contacts I logged were as they should be.

Changed to DM-780 and found one signal which I contacted and logged from DM-780 with no problem.

It appears that something in my original test database was creating the problem that could be replicated. This gives us some information we can use when troubleshooting customer complaints if we receive more on this issue.

I believe we can call this issue Resolved, and I apologize for the false alarm.

K7ZCZ

2019-10-07 22:16

administrator   ~0008769




No need to apologize -- at least, not for the false alarm.

If there is an issue with the software, we should try to capture it and fix it. If it's not related to a given Mantis issue, it's very easy to create a new isuse. If the issue can be made to reproduce, then we can find a fix for it. Even if an issue is not reliably demonstratable, a good description enables a focused investigation.

I'll mark this as resolved again, but feel free to open a new issue with a new description at any time.

g3ucq

2019-10-23 03:59

updater   ~0008925

Now I do not see duplication of data from one QSO to the next. Fixed for me.

WA9PIE

2019-10-23 04:06

administrator   ~0008926

Since Neil reported it, I'd like to see if Neil will test it before I mark it closed.

Issue History

Date Modified Username Field Change
2019-09-18 12:50 n4fn New Issue
2019-09-23 13:06 KB3NPH File Added: 2019-09-23 14_01_15-Window.jpg
2019-09-23 13:06 KB3NPH Note Added: 0008610
2019-09-23 13:23 PD9FER Note Added: 0008611
2019-09-23 14:28 w4ase Note Added: 0008619
2019-09-24 19:31 K7ZCZ Assigned To => n4fn
2019-09-24 19:31 K7ZCZ Status new => assigned
2019-09-24 19:32 K7ZCZ Status assigned => feedback
2019-09-24 19:32 K7ZCZ Note Added: 0008639
2019-09-24 19:33 K7ZCZ Module (select) => Logbook
2019-09-24 19:33 K7ZCZ Note Edited: 0008639 View Revisions
2019-09-25 07:50 KB3NPH Note Added: 0008655
2019-09-25 07:51 KB3NPH Assigned To n4fn => K7ZCZ
2019-09-25 08:40 K7ZCZ Note Added: 0008659
2019-09-25 09:03 KB3NPH Note Added: 0008660
2019-09-25 11:09 K7ZCZ Note Added: 0008664
2019-09-25 12:36 KB3NPH Note Added: 0008665
2019-09-25 12:49 w4ase Note Added: 0008666
2019-09-25 12:57 KB3NPH Note Added: 0008667
2019-09-25 13:37 g3ucq Note Added: 0008668
2019-09-25 14:48 WA9PIE Note Added: 0008671
2019-09-25 23:02 K7ZCZ Relationship added related to 0003432
2019-09-26 09:18 K7ZCZ Note Added: 0008697
2019-09-26 09:29 K7ZCZ Assigned To K7ZCZ => KB3NPH
2019-09-26 09:29 K7ZCZ Status feedback => new
2019-09-26 09:29 K7ZCZ Note Added: 0008699
2019-09-27 08:02 KB3NPH Note Added: 0008708
2019-09-27 08:48 K7ZCZ Note Added: 0008709
2019-09-27 08:48 K7ZCZ Status new => resolved
2019-09-27 08:48 K7ZCZ Resolution open => fixed
2019-09-27 08:48 K7ZCZ Note Added: 0008710
2019-10-02 16:15 KB3NPH File Added: 231 Alpha Test.jpg
2019-10-02 16:15 KB3NPH Note Added: 0008733
2019-10-02 16:20 KB3NPH Assigned To KB3NPH => K7ZCZ
2019-10-02 16:20 KB3NPH Status resolved => assigned
2019-10-02 16:20 KB3NPH Resolution fixed => reopened
2019-10-04 08:56 K7ZCZ Note Added: 0008741
2019-10-04 08:56 K7ZCZ Assigned To K7ZCZ => KB3NPH
2019-10-05 07:52 KB3NPH Note Added: 0008749
2019-10-05 07:53 KB3NPH Assigned To KB3NPH => K7ZCZ
2019-10-06 18:38 WA9PIE Project Issues Needing Retest => 3 - Current Dev List
2019-10-07 22:16 K7ZCZ Status assigned => resolved
2019-10-07 22:16 K7ZCZ Note Added: 0008769
2019-10-07 22:16 K7ZCZ Assigned To K7ZCZ => n4fn
2019-10-21 17:01 K7ZCZ Fixed in Version => 6.7.0.235
2019-10-23 03:59 g3ucq Note Added: 0008925
2019-10-23 04:06 WA9PIE Note Added: 0008926