LoTW Downloading failed either due to it being down or incorrect logins.

[MikleBas]

I can’t understand how the login or password is not correct if I go to Lotw with them and there are no problems.
How can I check if my actions are correct?
PS I configured via cron to send moss radio communications to the LOTW journal, but I can’t accept it from it for making edits, for the reason as in the screenshot

[simonszu]

I have the same problem at the moment.

[MikleBas]

did it work for you at all?
And at what point did it stop working properly?

[magicbug]

this codes not changed in a while so I don't think there's any new bugs, however, I'm guessing lotw logins was provided in the users account area?

[simonszu]

Sure :)

[magicbug]

I'm guessing your server can also reach ARRLs servers and this isn't a DNS/Network issue

[magicbug]

The other thing you could try is enable error logging /application/config/config.php then check /application/logs to see if anything shows

[MikleBas]

Log level 4 (all messages)
no error messages......

`
INFO - 2023-01-23 15:46:05 --> Config Class Initialized
INFO - 2023-01-23 15:46:05 --> Hooks Class Initialized
INFO - 2023-01-23 15:46:05 --> UTF-8 Support Enabled
INFO - 2023-01-23 15:46:05 --> Utf8 Class Initialized
INFO - 2023-01-23 15:46:05 --> URI Class Initialized
INFO - 2023-01-23 15:46:05 --> Router Class Initialized
INFO - 2023-01-23 15:46:05 --> Output Class Initialized
INFO - 2023-01-23 15:46:05 --> Security Class Initialized
INFO - 2023-01-23 15:46:05 --> Input Class Initialized
INFO - 2023-01-23 15:46:05 --> Language Class Initialized
INFO - 2023-01-23 15:46:05 --> Loader Class Initialized
INFO - 2023-01-23 15:46:05 --> Config file loaded: /www/wwwroot/hamlog.mysite.net/application/config/cloudlog.php
INFO - 2023-01-23 15:46:05 --> Config file loaded: /www/wwwroot/hamlog.hamlog.mysite.net/application/config/bands.php
INFO - 2023-01-23 15:46:05 --> Config file loaded: /www/wwwroot/hamlog.hamlog.mysite.net/application/config/lotw.php
INFO - 2023-01-23 15:46:05 --> Helper loaded: url_helper
INFO - 2023-01-23 15:46:05 --> Helper loaded: security_helper
INFO - 2023-01-23 15:46:05 --> Language file loaded: language/english/general_words_lang.php
INFO - 2023-01-23 15:46:05 --> Database Driver Class Initialized
INFO - 2023-01-23 15:46:05 --> Session: Class initialized using 'files' driver.
DEBUG - 2023-01-23 15:46:05 --> cURL Class Initialized
INFO - 2023-01-23 15:46:05 --> Migrations Class Initialized
INFO - 2023-01-23 15:46:05 --> Language file loaded: language/english/migration_lang.php
INFO - 2023-01-23 15:46:05 --> Database Forge Class Initialized
INFO - 2023-01-23 15:46:05 --> Model "Options_model" initialized
INFO - 2023-01-23 15:46:05 --> Controller Class Initialized
INFO - 2023-01-23 15:46:05 --> Helper loaded: form_helper
INFO - 2023-01-23 15:46:05 --> Language file loaded: language/english/lotw_lang.php
INFO - 2023-01-23 15:46:05 --> Model "User_Model" initialized
INFO - 2023-01-23 15:46:05 --> Upload Class Initialized
INFO - 2023-01-23 15:46:05 --> Model "Logbook_model" initialized
INFO - 2023-01-23 15:46:08 --> Final output sent to browser
INFO - 2023-01-23 15:46:08 --> Total execution time: 2.8083

`

[simonszu]

Same here. I set log level to maximum.

[gnoshme]

I got the same error, but on the download side. I think this is an error that occurs when trying to download from LoTW when it's log is empty. For me at least, it's worked itself out. LoTW.. wow. On par with eQSL for best 90s retro website.

[MikleBas]

Hi all!
Version 2.4 has already been released - but the problem with uploading to Lotw remained :)

[simonszu]

Check this out: https://yelling-at-clouds.gq/connecting-logbook-of-the-world-to-cloudlog/

[MikleBas]

I read your recommendations, but unfortunately they didn't work for me.
I come to the conclusion that using Lotw, Qrz.com is a waste of both money and time.
I am very impressed with the approach from the site https://www.qrzcq.com/ with its openness and monetary policy.
Lotw generally remained in its development in the late 90s of the last century. I no longer see any practical benefit for my CloudLog installation. I consider time and effort wasted on the Lotw resource - they are not justified by anything. IMHO
73! :)

[MikleBas]

Check this out: https://yelling-at-clouds.gq/connecting-logbook-of-the-world-to-cloudlog/

Yes, you were right in your article regarding Lotw - apparently there is a direct consequence when my qsl and qsl of my correspondent are uploaded to Lotw at the same time..
Yesterday I went through several qso, and one of the bottom immediately flooded the connection on Lotw - I also filled the communications in the evening and lo and behold, no error messages :)
I would like to convey this feature to Lotw for the CloudLog developer
Thanks for the valuable information!
73!

[DJLax5]

Hi everyone!
Did anyone find the cause of this? I've setup my LOTW Sync via a Cron Job and the upload is still working fine. However since end of February / beginning of March, cloudlog seems not be downloading the QSL Matches from LOTW correctly. I've only noticed that by accident, as none of my new QSOs have a LOTW QSL displayed in Cloudlog, however they do if I login to LOTW.
Downloading them into my QRZ.com Logbook works fine.
If I run the "Pull LoTW data for me from date" in Cloudlog, I get "Error: ADIF File Does Not Contain Any QSOs".
I don't think it's an authentication issue, as the upload works.

Any Ideas?

[MikleBas]

Hi, friend!
Yes, I confirm your observations, the symptoms are 1 to 1, I already thought that it was my glitches, it turns out I'm not alone :)
I honestly don't know how to solve the problem...

[DJLax5]

Do you have multiple LOTW certificates / station locations defined?
My issues started arising about 10 days after I added a new callsign certificate for my call /P for LOTW.

I have absolutely no clue what could have happend, so it stopped working.

[DJLax5]

I've found it!

Cloudlog tries to write to the file uploads/lotwreport_download.adi . The www-data group lost write permission on that file. I've added the write permission again, and now my lotw up- and download works as intended.

I susspect that this happend on March 1st, as I do the update cloudlog script once per month. Maybe something similar has happend to others.
To be fair, this may be a setup problem on my side...

[MikleBas]

Hi, friend!
Thanks, your advice helped me!
I have an update in the cron every night and the rights to the folders are constantly lost. Made an update on the crown once a month.
PS I already wrote something to the Author of the program - I need a script that checks the presence or absence of the necessary modules on the server and the presence of rights to important folders, because the one that is available is inconvenient:

1. you need to enter the development mode - and this interferes visually and it is not convenient to switch back
2. But even the script that is in the development mode incorrectly determines the rights to the folders and writes that everything is OK - although your and my experience say otherwise.
3. I propose to enable the verification script in the normal operating mode, by the way, it was there before, I see no reason why it was removed from there. Let at least it will be there for the Administrator.
   If the Author corrects our humble remarks, it will be to the benefit of everyone. IMHO :)

[phl0]

Sorry guys. It is a little late but I found the leisure to improve the code here. The error message regarding failed login is simply misleading. The improvements are contained in PR #2062. So feel free to checkout these changes. Feedback more than welcome.

[MikleBas]

I don't know how to tell if there was a mistake or not.

[MikleBas]

although the links have not yet been published on eqsl

[MikleBas]

maybe it's a locality glitch

[phl0]

Hu?! I thought we were talking about LotW issues here ...

[MikleBas]

sorry bro, missed the forum thread!

[ve3hls]

I'm having the same problem; getting the same error message when I manually sync to LoTW. Uploads work OK because I can logon to LoTW and see my verified QSOs.

Ken VE3HLS

[ve3hls]

I also tried manually updating a few logs in Cloudlog to show that they had been verified in LoTW. Those changes didn't 'stick' once made in Cloudlog. Seems like the only way to make them stick is if Cloudlog pulls the info off LoTW...