Date   
Re: QSORelay and HRD will not log

Chris VK2BYI
 
Edited

Here is your Session 20170524102621.log with explanations and a lot of detail removed:

2017-05-24 10:26:21.7147 Trace listener started
 
1. Contact sent by JTAlert received:
2017-05-24 10:45:18.1993 Processing received data
<CALL:5>DF8JK<QSO_DATE:8> .... <EOR>
 
2. Contact stored in the QSO Relay SQLite database file OK:
2017-05-24 10:45:18.1998 Logging contact in SQLite
Native library pre-loader is trying to load native SQLite library "C:\Program Files (x86)\VK2BYI\QSO Relay\x86\SQLite.Interop.dll"...
Insert Into [Log] ( QsoId, .... '', '', '' );
2017-05-24 10:45:18.5675 Contact successfully logged in SQLite
 
3. The conversation with HRD Logbook where the contact is accepted:
2017-05-24 10:45:18.5675 Relaying contact to HRD
[c] ver
Ham Radio Deluxe Version Release 6.4.0.647
[c] 
db add "MI1CCU" { CALL="DF8JK" QSO_DATE="20170524" .... QSO_COMPLETE="Y" }
Found 31 Valid Fields...
Added 31 Fields to MI1CCU...
[c] 
quit
[c] 
2017-05-24 10:45:21.9301 Contact successfully relayed to HRD
 
4. However, here is the problem.  QSO Relay is trying to verify if the contact has been added to the HRD Logbook database:
2017-05-24 10:45:21.9301 Verifying contact was logged by HRD
2017-05-24 10:45:21.9306 Checking HRD Logbook for DF8JK, 20170524, 094000, 20m, JT65
2017-05-24 10:45:26.1767 Retrying...
2017-05-24 10:45:27.1825 Retrying...
2017-05-24 10:45:28.1870 Retrying...
2017-05-24 10:45:29.1885 Retrying...
2017-05-24 10:45:30.1918 Retrying...
2017-05-24 10:45:31.1941 Retrying...
2017-05-24 10:45:32.1955 Retrying...
2017-05-24 10:45:33.1969 Retrying...
2017-05-24 10:45:34.1982 Retrying...
2017-05-24 10:45:35.2000 Retrying...
2017-05-24 10:45:37.9388 WARNING: Contact was not verified as logged in HRD
 
After 10 attempts at 1 second intervals, it still can't see the contact in the HRD Logbook and warns that it is not verified.  And a similar thing is happening with other contacts in this session log, and contacts in the other session log files you provided.
 
Can I assume that you see the contact eventually appear in MI1CCU HRD Logbook?
 
Whenever you see these repeated Retrying... statements as above, what is happening is that although the contact has made it as far as being accepted by HRD Logbook (step 3), HRD Logbook itself for some reason or other has taken more than 10 seconds to actually store the contact in your MySQL database.  In the meantime, QSO Relay has given up trying to verify it as being there.
 
I am a little astonished I must say, that HRD Logbook is taking that long to write the contact.  My testing reveals that it can take up to 5 seconds when a Microsoft Access database is being used, but with SQL Server and MySQL the contact is always verified on the first attempt, or second attempt at worst - never 10 attempts without success.
 
This is a nuisance but bearable, if the contact does eventually end up in the backend database.  In the next release, I will make the number of verification attempts a user-configurable setting.  In the meantime, I suggest you restart HRD Logbook when this occurs.

73 Chris
VK2BYI
 

Re: QSORelay and HRD will not log

Ian Morrow
 

Hi Chris

Further to your email

Thank you so much for getting back to me.

 

(Can I assume that you see the contact eventually appear in MI1CCU HRD Logbook?)

As to your Question, NO it does not appear in MI1CCU HRD Logbook at any time at all. 

It just says  WARNING  “Contact was not logged in Ham Radio Deluxe Logbook”

 

As I said before (I have to delete the QSO RELAY SQLITE DATABASE, create a new database, and then synchronise the database and then it works 100% again until I shut all down again.)

 

That is the only way I can get it to work.

If it would help you to have access to my Computer that is ok as I have Skype and Teamviewer on it , just let me know and we can arrange a time for you .

 

73’s

Ian MI1CCU/EI3HFB

Re: QSORelay and HRD will not log

Chris VK2BYI
 

Hi Ian,
That really is strange.
I will contact you direct.
73 Chris
VK2BYI

HRD Logbook Accepts But Fails To Log Contacts

Chris VK2BYI
 
Edited

I have been made aware of two QSO Relay users (Ian, MI1CCU/EI3HFB and Panos, SV8JNL) who are experiencing a problem with HRD Logbook not logging contacts.  They are both using Maria DB as the back-end database server.

Here is a snippet from a session tracing log captured by Ian, that shows the problem that both Ian and Panos are experiencing.  Some of the detail has been removed for clarity and replaced with 4-dot ellipses (....)

A contact from JTAlert is received:

2017-05-24 10:45:18.1993 Processing received data
<CALL:5>DF8JK .... <EOR>

The contact is written to QSO Relay SQLite database file:

2017-05-24 10:45:18.1998 Logging contact in SQLite

Insert Into [Log] ( QsoId, .... , '' );

2017-05-24 10:45:18.5675 Contact successfully logged in SQLite


The contact is relayed from QSO Relay to HRD Logbook.  Here is the conversation between QSO Relay and the HRD Logbook command line interface:

2017-05-24 10:45:18.5675 Relaying contact to HRD

[c] ver

Ham Radio Deluxe Version Release 6.4.0.647

[c] 

db add "MI1CCU" { CALL="DF8JK" .... }

Found 31 Valid Fields...

Added 31 Fields to MI1CCU...           <--- NOTE HRD Logbook indicates that 31 fields will be added to the 'MI1CCU' database

[c] 

quit

[c] 

2017-05-24 10:45:21.9301 Contact successfully relayed to HRD

QSO Relay then tries to verify that the contact has in fact been written to the database:
2017-05-24 10:45:21.9301 Verifying contact was logged by HRD

2017-05-24 10:45:21.9306 Checking HRD Logbook for DF8JK, 20170524, 094000, 20m, JT65

2017-05-24 10:45:26.1767 Retrying...

2017-05-24 10:45:27.1825 Retrying...

2017-05-24 10:45:28.1870 Retrying...

2017-05-24 10:45:29.1885 Retrying...

2017-05-24 10:45:30.1918 Retrying...

2017-05-24 10:45:31.1941 Retrying...

2017-05-24 10:45:32.1955 Retrying...

2017-05-24 10:45:33.1969 Retrying...

2017-05-24 10:45:34.1982 Retrying...

2017-05-24 10:45:35.2000 Retrying...

2017-05-24 10:45:37.9388 WARNING: Contact was not verified as logged in HRD

However, after 10 attempts at 1 second intervals, the contact cannot be found in the database.  A direct query of the database confirms the record has not been written.

I have never experienced this issue myself, but a close friend recently has, and he fixed it by completely uninstalling Ham Radio Deluxe using the freeware version of Revo Uninstaller, before re-installing it.  Although, he uses Microsoft SQL Server and not Maria DB.

Ian is going to attempt the reinstall as well.  Panos tried that, and that worked fine for him initially, but he now reports the same problem has returned.

Maria DB server is made by the original developers of MySQL, and is reportedly a binary compatible replacement for MySQL.  I have tested Maria DB on my development system with QSO Relay and HRD Logbook, and it works without any problems at all using MySQL Connection String properties.

I am aware of a long-standing issue in HRD Logbook, where a contact is only partially logged if an ADDRESS field contains carriage return and/or line feed characters.  However, in this case there is no ADDRESS field supplied in the data being sent to HRD Logbook, and it fails to log anything at all.

I am confident the issue lies within HRD Logbook and I have searched the HRDLLC Support Forum for an answer, but to no avail.  I would raise a ticket with HRD if I could reproduce the problem, but I can’t.

If any members reading this post can share their experiences and advice re Maria DB and HRD Logbook, I am sure Ian and Panos would be grateful.

73 Chris
VK2BYI

Re: HRD Logbook Accepts But Fails To Log Contacts

Morris WA4MIT
 

I am using Maria DB with HRD.647 with no issues I have logged many contacts now with QSOrelay without any difficulties. I have been setup on Maria DB for a good while now without any issues with it either. Get them to setup a dummy blank my access DB along with their in use Marie DB. JTAlert had a similar issue with Maria DB users and the blank dummy access DB was the fix. 73 wa4mit Morris



On Saturday, May 27, 2017 12:03 AM, Chris VK2BYI <chris@...> wrote:


I have been made aware of two QSO Relay users (Ian, MI1CCU/EI3HFB and Panos, SV8JNL) who are experiencing a problem with HRD Logbook not logging contacts.  They are both using Maria DB as the back-end database server.

Here is a snippet from a session tracing log captured by Ian, that shows the problem that both Ian and Panos are experiencing.  Some the detail has been removed for clarity and replaced with 4-dot ellipses (....)

A contact from JTAlert is received:
2017-05-24 10:45:18.1993 Processing received data
<CALL:5>DF8JK .... <EOR>

The contact is written to QSO Relay SQLite database file:
2017-05-24 10:45:18.1998 Logging contact in SQLite
Insert Into [Log] ( QsoId, .... , '' );
2017-05-24 10:45:18.5675 Contact successfully logged in SQLite

The contact is relayed from QSO Relay to HRD Logbook.  Here is the conversation between QSO Relay and the HRD Logbook command line interface:
2017-05-24 10:45:18.5675 Relaying contact to HRD
[c] ver
Ham Radio Deluxe Version Release 6.4.0.647
[c] 
db add "MI1CCU" { CALL="DF8JK" .... }
Found 31 Valid Fields...
Added 31 Fields to MI1CCU...           <--- NOTE HRD Logbook indicates that 31 fields will be added to the 'MI1CCU' database
[c] 
quit
[c] 
2017-05-24 10:45:21.9301 Contact successfully relayed to HRD

QSO Relay then tries to verify that the contact has in fact been written to the database:
2017-05-24 10:45:21.9301 Verifying contact was logged by HRD
2017-05-24 10:45:21.9306 Checking HRD Logbook for DF8JK, 20170524, 094000, 20m, JT65
2017-05-24 10:45:26.1767 Retrying...
2017-05-24 10:45:27.1825 Retrying...
2017-05-24 10:45:28.1870 Retrying...
2017-05-24 10:45:29.1885 Retrying...
2017-05-24 10:45:30.1918 Retrying...
2017-05-24 10:45:31.1941 Retrying...
2017-05-24 10:45:32.1955 Retrying...
2017-05-24 10:45:33.1969 Retrying...
2017-05-24 10:45:34.1982 Retrying...
2017-05-24 10:45:35.2000 Retrying...
2017-05-24 10:45:37.9388 WARNING: Contact was not verified as logged in HRD

However, after 10 attempts at 1 second intervals, the contact cannot be found in the database.  A direct query of the database confirms the record has not been written.

I have never experienced this issue myself, but a close friend recently has, and he fixed it by completely uninstalling Ham Radio Deluxe using the freeware version of Revo Uninstaller, before re-installing it.  Although, he uses Microsoft SQL Server and not Maria DB.

Ian is going to attempt the reinstall as well.  Panos tried that, and that worked fine for him initially, but he now reports the same problem has returned.
Maria DB server is made by the original developers of MySQL, and is reportedly a binary compatible replacement for MySQL.  I have tested Maria DB on my development system with QSO Relay and HRD Logbook, and it works without any problems at all using MySQL Connection String properties.

I am aware of a long-standing issue in HRD Logbook, where a contact is only partially logged if an ADDRESS field contains carriage returns and/or line feeds characters.  However, in this case there is no ADDRESS field supplied in the data being sent to HRD Logbook, and it fails to log anything at all.

I am confident the issue lies within HRD Logbook and I have searched the HRDLLC Support Forum for an answer, but to no avail.  I would raise a ticket with HRD if I could reproduce the problem, but I can’t.

If any members reading this post can share their experiences and advice re Maria DB and HRD Logbook, I am sure they would be grateful.

73 Chris
VK2BYI


Re: HRD Logbook Accepts But Fails To Log Contacts

Chris VK2BYI
 

Ah yes, I remember that happening with me and SQL Server some time back.  I had to have an empty Access logbook open in HRD Logbook at the same time as the SQL Server logbook that I use for my contacts, otherwise an 'unspecified error' kept popping up.  But I haven't needed to do that for quite some time now, and assume it was fixed.  I went looking through the HRD release notes forum looking for a mention, but I couldn't find it.

Those affected can try Morris' suggestion, can't hurt.  Thanks Morris.

73 Chris VK2BYI

Re: HRD Logbook Accepts But Fails To Log Contacts

Chris VK2BYI
 

Panos, SV8JNL, emailed me overnight and tells me he now has it working again without problem for 2 hours, and at the time of writing believes the problem is fixed.

He and a friend of his, were using the default 'mysql' database.  He created a new database without any tables in Maria DB, and then I presume he created a new ODBC Data Source Name for this database, and "opened" it with HRD Logbook so that it created the required 'table_hrd_contacts_v01' table.

Thanks Panos.

73 Chris VK2BYI

locked QSO Relay version 1.4

Chris VK2BYI
 
Edited

Please be advised that a new release of QSO Relay (Version 1.4) is now available for download at http://www.vk2byi.com.au/qsorelay/, or by selecting the Check for Updates... item on the QSO Relay menu.

This version is a minor release only, that addresses a couple of issues that have affected a very small number of users.  Most users will notice no change in functionality.

  • Handles ‘empty’ values in the Latitude, Longitude, My Latitude and My Longitude columns during ADIF logging file extract;
  • Rounds non-integer values in RX Power and TX Power columns during ADIF logging file extract;
  • Added RX Power field to ADIF logging file extract.

Again we wish to thank all users for their positive feedback and patience in working with us to resolve some of the issues experienced.

 

QSORelay and AVAST

Bob Davet
 

Just going to mention this because it has happened to me twice now on updates. Most recently on the 1.4 upgrade this morning. Just got home from work. Was tired and forgot to stop AVAST.

I am using AVAST as my virus protection. Seems to work for me.
I know the work around for it but sometimes I forget like I did this AM when updating to 1.4

AVAST does not recognize the program so it scans it then quarantines it and you have to send it and a bunch of other information to AVAST so they can make sure it is OK. That can take from 2 days to 2 weeks.

I have a workaround for it. When you get ready to install any QSORelay program and/or update just turn off AVAST for 10 minutes till QSORelay is done installing.Then everything is good.

Chris, can you possibly look into getting QSORelay checked by AVAST and any other antivirus program so this does not happen when people upgrade or install?? Don't know what is involved or how that is done. It would just be nice to not have to deal with this issue when installing or upgrading.

Thanks

Bob
W8RID

Re: QSORelay and AVAST

Chris VK2BYI
 
Edited

Or you could simply exclude 'C:\Program Files (x86)\VK2BYI\QSO Relay' and 'http://www.vk2byi.com.au/qsorelay/' as per these instructions from Avast: Excluding certain files or websites from scanning

Re: QSORelay and AVAST

Bob Davet
 

Chris:

 

Thanks. That was one thing I did not think of.

 

Bob

W8RID

 

From: vk2byi-qsorelay@groups.io [mailto:vk2byi-qsorelay@groups.io] On Behalf Of Chris VK2BYI
Sent: Sunday, May 28, 2017 7:58 PM
To: vk2byi-qsorelay@groups.io
Subject: Re: [vk2byi-qsorelay] QSORelay and AVAST

 

Or you could simply exclude 'C:\Program Files (x86)\VK2BYI\QSO Relay' and 'http://www.vk2byi.com.au/qsorelay/' as per these instructions from Avast: Excluding certain files or websites from scanning


Virus-free. www.avast.com

Re: HRD Logbook Accepts But Fails To Log Contacts

Chris VK2BYI
 

Ian, MI1CCU/EI3HFB, tried the suggestion from Morris, WA4MIT, and created a blank Access database and listed it directly under the Maria DB Logbook in HRD Logbook Manager.  I guess something similar to this:



After rebooting his computer, Ian now reports that it is working 100% - including after many subsequent reboots.

Thanks Ian a
nd Morris.

73 Chris
VK2BYI

Possible small Bug?

Morris WA4MIT
 

Chris I was looking at my HRD.647 DB with ADIF Master and I noticed that in the County Column with each JT QSO insert that the State is being inserted twice. This only started on May the 6th 2017 and this would be about the time I started using QSO RELAY this is only occurring with JT QSO`s. It looks like this AL. AL. Tuscaloosa. Prior to 5/6/17 the state is listed only once such as Al. Tuscaloosa. Not sure if this is a relay or JTAlert issue but wanted to let you know. Everything has been working great no hiccups or problems thanks for a great piece of software. 73 thanks Morris wa4mit

Re: Possible small Bug?

Chris VK2BYI
 

QSO Relay does not place any significance on individual fields, it simply relays the data received from JTAlertX to HRD Logbook.

However, it would appear that when you extract an ADIF file from HRD Logbook, it concatenates the State and County column values from the logbook and writes the result as the <CNTY> field in the ADIF file.

Here is a contact from my Logbook, where the County field is populated:



The same contact in the ADIF export file looks like this (with most of the detail cropped):
  ... <ant_el:3>0.0 <band:3>15m <band_rx:3>15m <call:5>K7VNE <cnty:11>AZ,Maricopa <comment:24>JT65 Sent: -10 Rcvd: -02 ...
And when opened in ADIF Master, it looks like this:



Check the contact back in HRD Logbook, and I think you will find that it has been logged correctly, with separate State and County values.  But in your case, I would guess you have 'AL.' in State and 'AL. Tuscaloosa.' in County.  And these values probably come that way from QRZ.com etc.

73 Chris VK2BYI

Re: Possible small Bug?

Morris WA4MIT
 
Edited

Hey Chris wonder where this is happening?. I looked in some recent log entries with county showing and this is not there in HRD on screen logbook but when I opened a adif save this is what I see in ADIF Master and if you notice there are a couple of PSK contacts in this and they are not double state??. Thanks for your reply 73 Morris

Re: Possible small Bug?

Chris VK2BYI
 

I assume that is the CNTY column on the left and the State column on the right you have circled.  Can I see what is in the County column for those contacts in HRD?

As I said in my previous post, what is exported in CNTY in the ADIF file, is actually State + County from HRD Logbook.  This is why you end up with 'DE' + , + 'DE,New Castle' in CNTY - it is HRD Logbook ADIF Export doing that.  I am guessing that either JTAlert and/or HRD Logbook is looking up details on a web service such as QRZ.com etc, and capturing those sorts of values.  But I do not know, I am only guessing.
 
But seeing as you asked... :-)

One way to help track it down is to Enable Tracing in the QSO Relay Options dialog, and work a few JT stations, then Disable Tracing so that the session file is closed and written.  Then examine the session file, or send it to me, and the details there will show what was sent by JTAlert and what was relayed to HRD Logbook.  For example, you will see this sort of thing:
 
A data packet from JTAlert is received - NOTE That there is no CNTY field in the following 'ADD' statement from JTAlert - but then County is not that relevant 'downunder', so I didn't expect it to be there. Your situation may be different:
    2017-05-07 20:02:15.9029 Processing received data
    ADD <CALL:6>VK2RTX<DXCC:3>150<COUNTRY:9>Australia<QSO_DATE:8>20170504<QSO_DATE_OFF:8>20170504<TIME_ON:6>070200<TIME_OFF:6>072000<FREQ:9>14.078902<FREQ_RX:9>14.078902<BAND:3>20m<BAND_RX:3>20m<MODE:4>JT65<DISTANCE:1>0<COMMENT:4>JT65<CQZ:2>30<ITUZ:2>59<PFX:3>VK2<CONT:2>OC<MY_GRIDSQUARE:6>QF55mx<MY_CQ_ZONE:2>30<MY_ITU_ZONE:2>59<STATION_CALLSIGN:6>VK2BYI<QSO_COMPLETE:1>Y <EOR>
 
The details are saved in the QSO Relay database (not relevant to this discussion):
    2017-05-07 20:02:15.9034 Logging contact in SQLite
    ...
    2017-05-07 20:02:16.1045 Contact successfully logged in SQLite
 
The contact details are relayed to HRD Logbook - NOTE: the detail layout is simply changed from the ADIF style provided by JTAlert, to the 'db add' syntax that HRD Logbook expects - but the values are not changed - so CNTY is not here either:
    2017-05-07 20:02:16.1055 Relaying contact via TCP to HRD
    ...
    db add "My Logbook" { CALL="VK2RTX" DXCC="150" COUNTRY="Australia" QSO_DATE="20170504" QSO_DATE_OFF="20170504" TIME_ON="070200" TIME_OFF="072000" FREQ="14078902" FREQ_RX="14078902" BAND="20m" BAND_RX="20m" MODE="JT65" DISTANCE="0" COMMENT="JT65" CQZ="30" ITUZ="59" PFX="VK2" CONT="OC" MY_GRIDSQUARE="QF55mx" MY_CQ_ZONE="30" MY_ITU_ZONE="59" STATION_CALLSIGN="VK2BYI" QSO_COMPLETE="Y " }
    Found 22 Valid Fields...
    Added 22 Fields to Access - W8RID...
    ...
 
The row is verified as written to the HRD Logbook database itself:
    Verify VK2RTX, 20170504, 070200, 20m, JT65
    2017-05-07 20:02:16.5600 Contact successfully relayed via TCP to HRD
 
Beyond all of this, it also depends upon what HRD Logbook does when it looks up details from web services, and how the details are formatted in those sources.
 
All I can say, is that QSO Relay does not change any of the details whatsoever - it just uses the formats required for accepting and relaying the details.  So, if it is not coming from JTAlert, then it is probably happening when HRD Logbook adds the record.  I suspect the later.

73 Chris VK2BYI
 

Re: Possible small Bug?

Chris VK2BYI
 

Found the answer!
This is what happens when I logged your call on my system (some detail cropped for clarity)...
2017-06-03 13:09:01.2595 Processing received data
    <CALL:6>WA4MIT<QSO_DATE:8>20170603<TIME_ON:6>030800...<CONT:2>NA<CNTY:13>AL,Tuscaloosa<DXCC:3>291<COUNTRY:13> ... <EOR>
 
So, JTAlert is suppling 'AL,Tuscaloosa' for CNTY.

You might ask the question on the HamApps forum, as a better answer will be found there.

73 Chris VK2BYI

Re: Possible small Bug?

Morris WA4MIT
 

Chris this subject has also been discussed on the HRD forum even Laurie VK3AMA commented on it and we all believe this is happening when QSO Relay sends data to HRD. Further I did a test to see if HRD somehow was causing this to happen. What I did was made a USA contact on JT65 using QSO Relay then did a ADIF export from HRD of this one qso and this contact showed the double state in the county field. I then deleted this one contact. JTAlert generates a file called "last qso" in ADI format so I imported this data (same qso same call) into HRD then again did a ADIF export and this time there was no double state in the county part of the ADI export. 
I believe this little experiment points to something happening when QSO Relay imports into HRD generating this anomaly.  What do you think?
73 Morris

Re: Possible small Bug?

Chris VK2BYI
 

Hi Morris,
I have just read the posts in the HRD forum and have posted a couple of replies.  I will have a new version of QSO Relay ready ASAP.
73 Chris VK2BYI

Re: Possible small Bug?

Morris WA4MIT
 

OK Chris again thanks for all your effort and sharing your fine software with all of us. 73 Morris