-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong import of adif file of another log program #455
Comments
Hi, and thanks for the answer. |
please, could you send us the impacted ADI records ? |
Good Afternoon |
Odd I tried an import into a test db and the first time I got similar results as you above. But I imported the file a second time it didn't error out on the last three entries. I tried in a fresh test directory and I didn't get the last 3 errors. I think those are generated because those lines don't have a STATION_CALLSIGN ADIF entry. But there are other lines that don't have it so I'm not sure what is going on there.. As for the DXCC - Ladislav - I wonder if someone doesn't have the Override DXCC checkbox selected should QLog try to lookup DXCC unless it is missing? Maybe put a change similar to this in LogFormat.cpp. |
Please, could you send me a screenshot of the setting for your station profile "Home"? |
please, add also a screenshot of the Help->About Dialog. |
I am afraid that it will be necessary to clean the data in LogHX or attempt to export it as ADX. Here's what I found:
Personally, I don't fully understand the error yet - the issue is still under investigation. However, this input file is so damaged that even if QLog managed to load it, I wouldn't trust the data very much. If possible, try generating an ADX file from LogHX (if that's an option) and try importing it to QLog. The ADX file supports non-ASCII characters. Maybe that will help the situation. Regarding the old DXCC entities, yes, that would be nice-to-have, but it's not the main issue with the import. |
In cases when an ADI record contains non-ASCII characters, Qt internally tries to interpret them as UTF-8 and convert them, which can lead to unpredictable behavior. This commit fixes the issue #455 as a side effect. Unfortunately, if the ADIF contains non-ASCII characters, QLog is still unable to handle them correctly - what is not an issue because ADI-format is defined as ASCII format.
It is opened a new issue for old DXCC Entity import issue - #459 |
HI Best regards |
Good evening
I probably found an error in importing adif logs.
When importing a log in adif format from another program, errors are always reported in the same serial numbers of the log itself, even if in reality the errors are not in the original log. Example:
[QSO#7001]: Error - A minimum set of fields are missing (start_time, call, band, mode, station_callsign) (2019-03-31; ; SSB)
[QSO#10001]: Error - A minimum set of fields are missing (start_time, call, band, mode, station_callsign) (2021-10-24; ; SSB)
[QSO#12001]: Error - A minimum set of fields are missing (start_time, call, band, mode, station_callsign) (2024-04-02; ; SSB)
If these are removed, in the new import of the correct log, the same reports are re-presented in the same serial numbers, even if the corresponding callsign has changed.
Furthermore, if callsigns are detected that do not correspond to DXCC countries, these are not imported into the QLog log. I think they should be imported anyway, but simply not counted in DXCC. In fact, it can happen that pre-existing DXCC entities no longer exist, but when they existed, the connections had been made and were valid.
Thanks and Best 73's
The text was updated successfully, but these errors were encountered: