bug in the upload process to eQSL.cc

[JA9HWD]

I compressed about 20MB of trace logs and sent them to [email protected].
Have you received it yet?

The email sending history shows "January 24th (Friday) 20:43 (4 days ago)". (This date is Japan Standard Time.)

[G4POP]

I compressed about 20MB of trace logs and sent them to [email protected].
Have you received it yet?

The email sending history shows "January 24th (Friday) 20:43 (4 days ago)". (This date is Japan Standard Time.)

He requested a 'Support request' see https://www.log4om.com/generating-a-support-request/

[JA9HWD]

I compressed about 20MB of trace logs and sent them to [email protected].
Have you received it yet?

The email sending history shows "January 24th (Friday) 20:43 (4 days ago)". (This date is Japan Standard Time.)

He requested a 'Support request' see https://www.log4om.com/generating-a-support-request/

Sorry. I emailed the trace log without understanding the part that said "Create a support request in help menu writing the call of the bad qso (log is very verbose in trace mode)".
For details, see "viewtopic.php?t=9521".
Perhaps "viewtopic.php?p=48952#p48952" is more important.

The timing of the trace is different, so it may not match up with the other data. For now, I put it in the temp folder together as a file called "To Log4OM_trace.zip".
If this doesn't work, I will create a report when the same problem occurs.

[JA9HWD]

With my regular account, Log4OM2 automatically uploads data after a certain amount of time has passed since the QSO. This is done properly every time a QSO is added.
However, when I search for "Request" in QSL Manager at a different time or on a different day, it is listed as an upload target, but when I press the "Uplaod Selected QSO" button and execute it, there is a duplicate error from eQSL.cc. You will see a message appear. Since it is actually uploaded properly, I thought it was an error in the search process and did not worry about it.
I have not actually encountered any adverse effects. Even if I report this as a bug, I think I will be called a liar or ignored again, so I have not reported it.

I just happened to reproduce this issue.
In this way, even though the file has already been uploaded successfully, it is listed and when I run it, it becomes a Dup.
I think this is the root cause.

Upload List 2025-01-29 095031.png (109.96 KiB) Viewed 20369 times

UploadResult 2025-01-29 095310.png (96.32 KiB) Viewed 20369 times

[JA9HWD]

I confirmed that this occurred again today. It seems to be occurring more frequently than I thought.
When I checked the QSL Manager, the uploaded QSOs were listed, so I set the log to trace mode and ran it.
However, when I looked at the trace, all I could see was that a Dup error occurred. It seems that this phenomenon requires tracing at the time when "Request" could not be set to "Yes".
However, I cannot continue to spit out such a large log file (6MB for processing only one station) without knowing when the phenomenon occurs, so please forgive me.
When I look at the "log.adi" for support requests, EQSL_QSL_SENT is "Y". I don't know if this was set to "Y" because of the Dup error, or if it was "Y" from the beginning when I started this.
I'll leave this series of bug reports as ``couldn't be resolved'' due to my lack of ability. This ends with me giving up.

[G4POP]

Its possible the FT8 software is either uploading or marking the QSO as sent Y before its saved to Log4OM

We cant be of more help until you provide Lele with a support request!

[JA9HWD]

Its possible the FT8 software is either uploading or marking the QSO as sent Y before its saved to Log4OM

We cant be of more help until you provide Lele with a support request!

Are they looking at the support requests I've already sent? What are they looking at?
The DB contents were attached, but the bug is that even though the status was "Y", QSL Manager recognized it as a "Request" and uploaded it.
If it was changed to "Y" in another app it shouldn't be listed for uploading in QSL Manager. And yet it was uploaded.
That's all.

[G4POP]

Its possible the FT8 software is either uploading or marking the QSO as sent Y before its saved to Log4OM

We cant be of more help until you provide Lele with a support request!

Are they looking at the support requests I've already sent? What are they looking at?
The DB contents were attached, but the bug is that even though the status was "Y", QSL Manager recognized it as a "Request" and uploaded it.
If it was changed to "Y" in another app it shouldn't be listed for uploading in QSL Manager. And yet it was uploaded.
That's all.

As far as I am aware Lele has not receved support requests from you I will check with him

[JA9HWD]

Its possible the FT8 software is either uploading or marking the QSO as sent Y before its saved to Log4OM

We cant be of more help until you provide Lele with a support request!

Are they looking at the support requests I've already sent? What are they looking at?
The DB contents were attached, but the bug is that even though the status was "Y", QSL Manager recognized it as a "Request" and uploaded it.
If it was changed to "Y" in another app it shouldn't be listed for uploading in QSL Manager. And yet it was uploaded.
That's all.

As far as I am aware Lele has not receved support requests from you I will check with him

The email was sent normally with the following content. Please check.
The size is large, so it may have exceeded the size limit at the MTA or mail server along the way, but this is not known to the sender.
The attachment was 4.2MB after zip compression.

{
MIME-Version: 1.0
Date: Tue, 28 Jan 2025 13:43:36 +0900
Message-ID: <CA+u9A7nok-i6SZv1Q7iOh1FL+pTsb89CDgNy4QPP_xX7E84obA@mail.gmail.com>
Subject: JA9HWD_20250128043053
From: Kiyoshi Koshiyama <[email protected]>
To: [email protected]
Content-Type: multipart/mixed; boundary="0000000000000b8c34062cbcd659"

--0000000000000b8c34062cbcd659
Content-Type: text/plain; charset="UTF-8"

I will send you the zip file that was created via the support request.

--0000000000000b8c34062cbcd659
Content-Type: application/x-zip-compressed; name="JA9HWD_20250128043053.zip"
Content-Disposition: attachment; filename="JA9HWD_20250128043053.zip"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_m6fzrkj50
Content-ID: <f_m6fzrkj50>


--0000000000000b8c34062cbcd659--
}

[IW3HMH]

i have your mail, need a bit of time to check it out and reproduce
probably will not be released in the very next version