Trouble getting opencage to work.

[grheard]

Let me start by saying that this is probably a user error, but for the life of me, I cannot figure it out.

I installed the docker image on my unraid server. I have tried passing the OTR_GEOKEY from the -e docker variable definition and in the recorder.conf file. When I pass it into the container, I can start a shell in the container and when I check the exports it is listed and has the "opencage:xxxxx" (correct key instead of x) around it as described in the documentation. I get no indication of lookup failures (no 'missing' file in the ghash directory) nor do I get an address lookup. I have verified that the container can get to https://api.opencagedata.com/ by assembling the same url that recorder creates in geo.c and executing curl inside the container. The result is successful with the correct address.

Any insights on what to check next?

Also, how would you pass the --debug into the container?

Like I said, this is probably on my end, but I am unsure where to look next.

[jpmens]

I'm sorry you're having trouble with this, and thank you very much for trying almost everything there is to try! Do note that since version 0.8.1 the environment variable overrides a recorder.conf setting.

Are you able to modify the startup flags of the ot-recorder and add "--geokey opencage:xxxx" explicitly? Does that change anything.

Also when you've got the container running and you submit a position to ot-recorder, what do you see on its console? You ought to see the position (lat, lon) and some indication on the reverse geo lookup.

[grheard]

Thanks for the quick reply.

I've removed the OTR_GEOKEY from both the docker definition and the recorder.conf file. I've added --geokey "opencage:xxx" to the entrypoint.sh file (along with --debug).

ot-recorder "$@" --geokey "opencage:<redacted>" --debug

Here is the output I am getting on the console:

+++++ [in hook_revgeo()] * 18:14:55 <topic redacted> t= tid=<tid redacted> loc=<coords redacted> [] (dnqvhb9)

[grheard]

Okay... this is interesting. I've got it working.

So... when I first initialized the docker image, I didn't have a geokey. So after getting recorder up and seeing that it was working, I then went back and added the geokey, but lookips weren't taking place and I started this thread.

On a lark, I stopped the image. Erased the store. Started the container without changing anything else. Viola. Lookups are now taking place.

Edit:

I went back and removed the changes to entrypoint.sh and applied the OTR_GEOKEY docker environment variable. Lookups continue to work correctly. It seems that something about the initial setup in the store without a geokey defined broke adding a different geokey. Something left behind about the default google lookup perhaps?

[jpmens]

I stopped the image. Erased the store. Started the container without changing anything else. Viola. Lookups are now taking place.

This is of course as they say: impossible. But in our world of IT nothing is impossible.

At the very least it is surprising: neither the lookup method nor the geokey are stored anywhere so what you describe is, well, surprising. :-)

I'm quite sure there's a bug lurking there somewhere ... and I'm marking this as a bug until I can give it a closer look.

I'm glad you got it working, and thank you for reporting back.

[grheard]

Given your response, I attempted to recreate the scenario.

I can recreate the original problem 100% of the time.

Here is my setup.

UnRaid 6.9.2 with Docker 20.10.5 (in case it means anything)

1. Install docker image without OTR_GEOKEY being set and no previous store directory.
2. Run the image.
3. Collect a few position messages from OT.
4. Stop the image.
5. Add the OTR_GEOKEY (either by docker variable or in the config file).
6. Start the image.
7. Using the container console, verified that OTR_GEOKEY is in the environment and correct.
8. No reverse geo lookups observed.

Weird steps to correct the problem:

1. Stop the previous image.
2. Only remove the store directory.
3. Start the image.
4. Observe reverse geo lookups succeed.

One last observation. When the reverse geo lookups are not taking place, there isn't even evidence that they were attempted. There are no outgoing ports ever created. When lookups are happening it is easy to spot the outgoing ports being created and closed. These observations were done using netstat in a fast loop (every 100ms) from the console inside the container.

As I can recreate this scenario at will, If there is anything you need from me or anything you want me to try, let me know.

[jpmens]

Am I right in thinking you haven't actually moved the phone significantly between collecting a few position messages and the removal of the store directory?

We cache the results of reverse geocoding, and I suspect ot-recorder is feeding back the last (possibly unsuccessful) cached entry instead of going out afresh to OpenCage. This would explain why your removal of the store directory has an effect.

[grheard]

That would be correct. The location hash was the same from all the phones while I was doing this.

[jpmens]

I will add a note to our Recorder documentation about this.