Closed g7kse closed 5 years ago
You need to run the Admin / Update Tools routine to import and create dxcc entity information .....
Yep, this caught me out, need to add a notice to run it after first install
Had done that but did it again but no joy. Are there any logs I can check? I'm a bit out of my depth here. Is the RPi zero W a problem?
edit - I had a quick look in the myphpadmin page and looked in the tables and there are two dxcc exceptions tables dxcc_exceptions and dxccexceptions
edit 2 - Actually this might help
RPi zero isn't the problem; I'm running on an RPi 1 which has similar performance.
You could install phpmysqladmin and have a poke about to see whether the dxcc info has been imported OK? (But be very careful if you don't know what you're doing with mysql!)
On another note, I can't seem to get an ADIF to upload to the server to begin the import in the first place! (I'm currently hacking about to see where the bug is .... If it even is a bug!)
Ah ha.....I think I have found a little clue. ADIF from clublog is slightly different from one from HRD I have. The header os the file in HRD was uploaded without problems and had '#' in front of the header whilst the one from clublog didn't
Here's the one from clublog
Here's the one from HRD
Adding in the '#' seems to do the trick as adding them to the clublog one like this
and it all uploads nicely. The sad thing is that I've only logged 18 QSO's this year....I really ought to get the sota ones and contest ones in the log ;-)
Confirmed!! I was struggling to upload an ADIF file generated by eQSL - I originally imported from an ADIF from HRDlog.net.
Guess what? eQSL have comments in the header without a leading # - ADIF file manually edited, problem solved!
Incidentally, the server was rejecting the file without the leading # characters regardless of file name or allowed_types setting. I suspect the automatic mime type sense is being triggered by the file format if it has lines without a leading #. More testing on this one required, however, I don't think there's much we can do about it except be aware that this is the cause of this problem; it seems to be a gotcha in whichever service generated the ADIF, not Cloudlog :-)
If only sites kept to the adif spec!
That said probably should adjust the script to ignore the stuff before the adif begins if other sites are doing it
It does seem the only common successful upload this far has been from hrdlog!
However, my system was failing to even upload the file - the PHP was complaining about file types which is a CodeIgniter thing from what I could tell, and not an ADIF parser failure.
Based on my usage app uploads are wsjt, mixw, FL-digi, n1mm, WinTest, dxlog, winlog32 & pztlog
Sadly adif spec is loosely followed, but if it conforms it should import.
If not feel free to open a support issue for each app we might be able to build in work arounds.
Other thing you might have to watch out for is PHP process timing out if it's taking to long to load
Just probably needs a note in the wiki about the adif spec. If I can fix it anyone can ;-)
After all it isn't a big deal at all to check and fix. Especially as if there is a standard and it isn't being followed, I wouldn't expect it to work. btw my original adif was from cqrlog. I guess this closes the case Dr Watson
Windows 10 Firefox 63.03 & Edge Server running as LAMP on RPI zero (i.e. not localhost)
On attempting to upload adi button is available. File can be selected
File is selected (as a download of clublog - with adi extension)
It looks like it is uploading but then returns error as below
Checked in 'Uploads' directory but it is empty. On one occasion it did give me a DXCC error briefly as below
I'm not convinced it is a bug as I can manually add a qso but I did run into permissions in the early part of the DB installation but as I can enter a qso normally can you investigate. I assume that manaully uploading the adi to uploads without runnig a script will do nothing.