ExifToolGUI 6.3.3.0 - geocoding disabled without a message and access violatio

Started by herb, July 06, 2024, 11:24:17 AM

Previous topic - Next topic

herb

Hello Frank,

I played with geocoding of ExifToolGUI 6.3.3.0.
I opened the OSM-map and entered various names of existing and not existing cities or only part of a city.
I also changed the geocoding engine very often.
Hint: I do not have any api-key for geocode.

At begin for each search a result window was shown.
Depending of the search-string it contained some results or was empty.
Then ExifToolGui went into a state in which no more result window was displayed.
After some search I found that geocoding was disabled without any message or popup.
(Sorry, but I have no golden rule how to come into this state).

I re-enabled geocoding and searched again - e.g. for Amsterdam with geocode engine.
The result was an access violation and a stack trace was generated.

I can reproduce the access violation with the attached *.ini file.
- start ExifToolGUI with this ini file
- open OSM map
- re-enable all geocoding
- search for Amsterdam with geocode engine
  (please be aware that I do not have any api-key)
- after the popup-hint it comes to the access violation

The attached *.zip file contains the *.ini and 2 *.txt files with stack-traces.

I hope this helps
Best regards
herb

FrankB

Hello Herb,

First a few remarks that have no relation with the AV, but I still would like to make.
- You mention version 6.3.3.0, but I assume you mean the pre-rel I sent you?
- The stacktrackes are not very useful, likely because the corresponding map files are not available. Note: The correct map files where not distributed, so I'm not blaming you.
- It is sometimes useful to open the log window to debug problems. In this case it was obvious that HTML was returned. See log window

The cause for the AV is an incorrect URL specified for GeoCode. Dont know how you managed to do that.
You have https://nominatim.openstreetmap.org in the ini file, but it should be: https://geocode.maps.co

The code expects that the webservice returns valid JSON, but your URL returns HTML. I agree that GUI could be improved by first checking if the JSON is valid.

See screenhot:
pref.jpg

Log Window:
log.jpg

herb

Hello Frank,

thanks for your quick reply and for your detailed analysis.

This post is for the official version ExifToolGUI 6.3.3.0.
Writing this post I did not know that you created a pre-release 6.3.4

Yes you are right I had changed the URL of GeoCodeMaps ( a long time ago ).
Starting my test yesterday I did not remember this change.
I apologize if this had caused the problems/errors.

Maybe you should not allow to change this URL?

I will restart my tests from scratch, of course with unchanged URL

Thanks also for the pre-release 6.3.4. Of course I test it.
But please be patient, it will take some days.

Best regards
herb

FrankB

Quote from: herb on July 06, 2024, 02:54:06 PMI apologize if this had caused the problems/errors.

No problem.

Quote from: herb on July 06, 2024, 02:54:06 PMMaybe you should not allow to change this URL?
Short answer: No.
I would like GUI to be as flexible as possible. Suppose the webservice provider changes the URL? 

Quote from: herb on July 06, 2024, 02:54:06 PMBut please be patient, it will take some days.

No hurry.

herb

Hello Frank,

I started the geo-coding tests with 6.3.4pre.

(1)
I played with "Geotag files" and used very often "Setup Geo".
2 times I got the following error:
QuoteException: List indiex out of bounds (2). TValueListStrings object is 0..1 occurred.
Copy stacktrace ...
But I do not have a rule how to reproduce.

(2)
I could also reproduce the access violation.
I started ExifToolGUI with a directory that contains 1 image. This image has no XMP-tags and also no GPS-tags.
The map is started with "Home" value. Select a point different to: 52.37454, 4.897976
"Geotag files" failed because the used method "GeoCode" was started without an api-key.
I started "Setup Geo" which failed (of course) again.
I re-enabled geocoding within the following popup message and started "Setup Geo" again.
Now the access violation message was displayed.

(3)
Starting test (2) with "Home" value == 52.37454, 4.897976
"Geotag files" gets proper values for a point in Amsterdam.
How does it get these values as "GeoCode" is set to be used and has no api-key?

(4)
Same start as in (3).
In "Geotag files" windows all values are available.
Starting "GeoCode" again seems to do nothing.
Is this correct?

Best regards
herb

FrankB

Hi Herb,

I will look into 1) and 2), but first I need to update the installer.
https://exiftool.org/forum/index.php?topic=16201.0
Edit: I would help very much to have the stack trace. PLease also place the corresponding map file next to the exe, so I get method names in stead of addresses.

About 3) and 4)
I just noticed that GeoCode does not (always) reject calls that dont have an api_key. Maybe just temporary.

Edit: Lat/Lon randomly chosen. If an API_KEY is entered GeoCode will check. try with 'NO_KEY' for example

https://geocode.maps.co/reverse?lat=51.3399878&lon=6.669237
geocode.jpg

herb

Hello Frank,

thanks for update to prerelease 2.
Till now all tests were done with prerelease 1.

What is the name of the *.map file?
I guess it does only differ in the file-extension:
so ExifToolGUI_634pre-2.exe needs an ExifToolGUI_634pre-2.map
Am I right?

Best regards
herb

FrankB

I normally dont rename the exe. For another version I will use a different directory. So I'm not sure, but I think you're right.

I'm about to release 6.3.4 Sometime today. So better not waste your time on a pre-rel. My remark on the map files was meant in general.

herb

Hello Frank,

attached please find 2 stacktraces:
- stacktrace_1 is for wrong indexing and
- stacktrace_2 is for access violation.

I used ExifToolGui_X64.exe together with ExifToolGUI_X64.map as sent by you for prerelease 2.

I hope the traces will help.
Best regards
herb


FrankB

Hi Herb,

Just released V6.3.4. https://github.com/FrankBijnen/ExifToolGui/releases/tag/V6.3.4

Besides the fixed installer it also fixes the 'Stacktrace_index', and probably also the Stacktrace_accessviolation'. They have nearly the same callstack.

Frank

herb

Hello Frank,

thanks for the release of version 6.3.4.
I tried to reproduce the errors with this version; but all was working properly.

Best regards
herb