Log4OM2 does not search QRZ.com

[JA9HWD]

First, try entering the following two call signs in the call sign field of Log4OM2.
8J150CB/P
8J7KJ4O/7
These two are the call signs of amateur stations officially issued by the government and are also registered on QRZ.com.
However, 8J150CB/P is searched correctly and the name etc. are displayed, but 8J7KJ4O/7 is not searched. In both cases, it is normal for the portable notation at the end of the call sign to be automatically removed by QRZ.com and searched.

When I posted this situation as a bug report on Facebook's Log4OM forum, the answer was
I was called a liar by saying, "It's not a bug, it's a non-standard call sign," "That's a CB call sign," and "Non-standard call signs are not handled by Log4OM2."
I tried adding it to "NonStandardCallsign.txt", but the result does not change.
I'm tired of the useless Facebook forum conversations.

If it's a bug, I'd like it to be fixed, and even if it's not a bug, I'd like Log4OM2 to accept the input callsign without any unnecessary checks, so I posted it here.
Since the call sign sent by the QSO partner is entered in the call sign field of Log4OM2, whether it is standard or non-standard should not matter to Log4OM2. At least when searching QRZ.com, I don't think it's necessary to check with Log4OM2.

To find out, search for the two call signs directly on QRZ.com. For either callsign, the page will be searched and displayed.
Next, try pasting the two callsigns into the callsign field of Log4OM2.
8J150CB/P is searched normally, but 8J7KJ4O/7 is not searched.
Please try checking it out.

My environment is as follows
Log4OM version: 2.32.1.0
Windows OS version: 11

[G4POP]

Dear Kiyo,
I have just spent some time checking this and engaged out trace and debug modes while doing so.

Whereas I get a data response from QRZ for the 8J1 call sign I get zero data response for the 8J7 call, no replu from QRZ! Log4OM first checks QRZ using the call including the suffix and then if no reply we interogate again without the suffix so we are trying hard to obtain the information!

Please be aware that when software interogated QRZ for a lookup it is via a QRZ API which does not always contain the same information found on a web site lookup, we do not scrape the web page as some apps do.

The ONLY suffixes recognised by logging software are /P, /MM, /A, /AM and /M - We have no reference to consult to obtain the /# suffixes often used by some stations.

Additionally I note that you are not a paid xml subscriber to QRZ, your a ham member, so you wont receive a full data lookup.

NonStandardCallsign.txt

I assume that you used the 'Resources editor' in the settings menu? It does work just make sure that you save and restart Log4OM to implement it

[JA9HWD]

Dear Terry,
Thank you for taking your valuable time to investigate.
It's unfortunate that NonStandardCallsign.txt has no effect, but when I check the "Resources editor" now, I can see that 8J7KJ4O has been added. I was wondering if it would be okay to just use the prefix, but I couldn't decide and added "8J7KJ4O" instead. Maybe just the prefix was fine.
I think it's strange that when I search manually on the web, everything is fine, but Log4OM2 returns an error.
On the Log4OM2 screen, in the case of 8J7KJ4O/7, "[SEARCHING...]" is displayed momentarily and then disappears.
I don't think it matters whether I am a paid subscriber or not for the processing up to this point in Log4OM2.
Even if the search fails, the log itself will be entered, so it is not a big problem.

In actual operation, there is no input in the call sign field of Log4OM2, and "DX Call" from WSJT-X or JTAlert is placed in the call sign field of Log4OM2 by UDP transfer. At that time, Log4OM2 is executing the search, but I don't think the search results at this time are used. ADIF files are transferred to Log4OM2 as log data when the QSO ends. So I don't have time to check the search results.
If I think about it, Log4OM2 may be searching on QRZ.com twice, once when placed in "DX Call" and once when transferred from an ADIF file. Although it is undesirable to search twice, this flow is required to avoid bugs in WSJT-X and Log4OM2.

This time, on Facebook, I was called a liar without checking the reproduction method I presented, so I was a little angry, so I apologize for the inconvenience.
--
73, Kiyo

[G4POP]

I think it's strange that when I search manually on the web, everything is fine, but Log4OM2 returns an error.
On the Log4OM2 screen, in the case of 8J7KJ4O/7, "[SEARCHING...]" is displayed momentarily and then disappears.
I don't think it matters whether I am a paid subscriber or not for the processing up to this point in Log4OM2.
Even if the search fails, the log itself will be entered, so it is not a big problem.

I did try to explain why in this statement in my last post

"Please be aware that when software interogates QRZ for a lookup it is via a QRZ API which does not always contain the same information found during a web site lookup, we do not scrape the web page as some apps do."

In other words sometimes the data supplied by QRZ to Log4OM via the API lookup is not always the same as you will see on the QRZ website

Set Log4OM to Trace or debug mode and watch the realtime log and you will see what happens when Log4OM is doing a lookup

Adding just the prefix to the non standard call sign list (NSCL) will exclude all calls with that suffix instead of just the one call.

When a call is in the NSCL the lookup is not carried out at all so nothing will be seen in the input GUI

Incoming data via UDP goes through the same lookup routine if you have instructed the UDP connection to use lookup

[JA9HWD]

thank you.

I tried collecting Log4OM2 logs. Looking at this, it looks like you haven't even accessed QRZ.com.
When I enter 8J7KJ4O/7 and delete each character with Back Space, many WORKED BEFOREs are displayed, but 8J7KJ4O/7, which has already been QSOed, is not displayed in WORKED BEFORE.
So, it is probably not a problem with QRZ.com, but that it is not recognized as a call sign.

--
Kiyo

[JA9HWD]

It's unfortunate that NonStandardCallsign.txt has no effect, but when I check the "Resources editor" now, I can see that 8J7KJ4O has been added. I was wondering if it would be okay to just use the prefix, but I couldn't decide and added "8J7KJ4O" instead. Maybe just the prefix was fine.

This was a misunderstanding. It's no good to add it here. It has been deleted.
--
73, Kiyo

[JA9HWD]

I'm curious why it sends 8J7KJ4O to fldigi when Log4OM2 says it doesn't recognize it as a valid callsign.

copy2024-04-01 203819.png (93.69 KiB) Viewed 834 times

--
Kiyo

[JA9HWD]

I think it's strange that when I search manually on the web, everything is fine, but Log4OM2 returns an error.
On the Log4OM2 screen, in the case of 8J7KJ4O/7, "[SEARCHING...]" is displayed momentarily and then disappears.
I don't think it matters whether I am a paid subscriber or not for the processing up to this point in Log4OM2.
Even if the search fails, the log itself will be entered, so it is not a big problem.

I did try to explain why in this statement in my last post

"Please be aware that when software interogates QRZ for a lookup it is via a QRZ API which does not always contain the same information found during a web site lookup, we do not scrape the web page as some apps do."

In other words sometimes the data supplied by QRZ to Log4OM via the API lookup is not always the same as you will see on the QRZ website

Set Log4OM to Trace or debug mode and watch the realtime log and you will see what happens when Log4OM is doing a lookup

Adding just the prefix to the non standard call sign list (NSCL) will exclude all calls with that suffix instead of just the one call.

When a call is in the NSCL the lookup is not carried out at all so nothing will be seen in the input GUI

Incoming data via UDP goes through the same lookup routine if you have instructed the UDP connection to use lookup

When I tried setting the same user and password for fldigi as I had set for Log4OM2 and put 8J7KJ4O/7 in the call sign, the page was displayed in the browser and the name was displayed in the Op field of fldigi. I'm not convinced by the difference between this and Log4OM2's behavior.
So at least I don't think it's a problem with QRZ.com.

8J7KJ4O_fldigi 2024-04-02 213102.png (65.88 KiB) Viewed 780 times

[JA9HWD]

The same thing happens with the call sign 8J4Y70A. However, 8J4Y70A is not registered on QRZ.com.
There may be a bug in the call sign analysis process, apart from the QRZ.com search.
This is a call sign that is actually used, so please improve it so that it is processed correctly.
ADIF file linkage will write correctly to the log without entering it in the callsign field. Even if you enter the same call sign in the call sign field, it will not be displayed in the Worked before window.

[JA9HWD]

I think I've found the cause.
I found that if I copied and pasted this call sign "8J7KJ4O/7" into the call sign field of Log4OM2, there would be no response.
However, if I input each character by hand, it will also be displayed in "Worked before".
I think the same thing as this copy-and-paste situation occurs when inputting from UDP. In other words, it appears that Log4OM2 cannot keep up with the fast input and abandons processing midway through.
This has nothing to do with QRZ.com.
To verify this, try inputting each character manually and comparing input using copy and paste.