Map is empty, metadata cache missing GPS coordinates

[Terrance]

Having left Photofield to go through and index all my photos, it seems to have not pulled any location information from my metadata, and the map view comes up empty. Peeking in the cache database:

$ sqlite3 -readonly photofield.cache.db
sqlite> select count(*) from infos where longitude != 0.0;
0

I can't see anything obvious in the logs relating to GPS coordinates (or lack thereof).

Example tags present in a photo:

$ exiftool IMG_….jpg | grep GPS | grep -Ev 'Date|Time'
GPS Latitude Ref                : North
GPS Altitude Ref                : Above Sea Level
GPS Processing Method           : GPS
GPS Longitude Ref               : West
GPS Altitude                    : 53.1 m Above Sea Level
GPS Latitude                    : 51 deg 28' 59.04" N
GPS Longitude                   : 0 deg 0' 37.54" W
GPS Position                    : 51 deg 28' 59.04" N, 0 deg 0' 37.54" W

For what it's worth, most of my photos have had a pass through Digikam where I curate my photo tags,

[SmilyOrg]

Hi! A few questions:

1. Is exiftool available where you're running photofield?
2. Do you see exiftool running as a child process? Esp. taking CPU while indexing.
3. What do you get if you run exiftool -S -GPSLatitude# -GPSLongitude# img.jpg?

If you have a sample image with the problem I can also try debugging it.

[Terrance]

1. I set it going with reindexing so I could keep an eye on it, but I note the following on startup:

   unable to use exiftool, defaulting to goexif - no video metadata support (Could not create StayOpen: Failed starting exiftool in stay_open mode: exec: "exiftool": executable file not found in $PATH)

   This might be a bit funky on Arch:

   $ which exiftool
   /usr/bin/vendor_perl/exiftool

   However, I'm fairly sure that /usr/bin/vendor_perl is in my $PATH and it's not being recognised. systemd services seem to use a tighter path that doesn't include Perl modules, but I've tried both in a shell with $PATH set correctly, and with a service that manually sets $PATH and verifies it with an ExecStartPre to print it from another shell -- I still get executable file not found in $PATH in both cases.

   I'm also seeing a lot of messages like the following (all for videos, not images) -- not sure if this is a quirk of falling back to goexif or unrelated:

   Unable to load image info meta image: unknown format /srv/media/photos/…/VID_.….mp4

   I've not customised the file extension config, so I assume it's recognising .mp4 as video but tripping over them somehow.

2. Probably obvious from the above, but no exiftool processes are launched -- during the index metadata stage, photofield itself is sitting at about 10% CPU whilst indexing, but no other processes are being launched. At index contents, I'm seeing ffmpeg (~5 parallel processes, presumably generating thunbnails) but again no exiftool.

3. $ exiftool -S -GPSLatitude -GPSLongitude IMG_….jpg
   GPSLatitude: 51 deg 28' 59.04" N
   GPSLongitude: 0 deg 0' 37.54" W

[SmilyOrg]

unable to use exiftool, defaulting to goexif - no video metadata support (Could not create StayOpen: Failed starting exiftool in stay_open mode: exec: "exiftool": executable file not found in $PATH) This might be a bit funky on Arch:

$ which exiftool
/usr/bin/vendor_perl/exiftool

However, I'm fairly sure that /usr/bin/vendor_perl is in my $PATH and it's not being recognised. systemd services seem to use a tighter path that doesn't include Perl modules, but I've tried both in a shell with $PATH set correctly, and with a service that manually sets $PATH and verifies it with an ExecStartPre to print it from another shell -- I still get executable file not found in $PATH in both cases.

Ah that will do it. To get GPS coordinates it needs to use exiftool currently. I'm not sure why it wouldn't pick it up from path, it's more or less a standard exec.Command call calling exiftool.

I'm also seeing a lot of messages like the following (all for videos, not images) -- not sure if this is a quirk of falling back to goexif or unrelated:

Unable to load image info meta image: unknown format /srv/media/photos/…/VID_.….mp4 I've not customised the file extension config, so I assume it's recognising .mp4 as video but tripping over them somehow.

Yes, this is the fallback goexif loader not knowing what to do with mp4.

2. Probably obvious from the above, but no exiftool processes are launched -- during the index metadata stage, photofield itself is sitting at about 10% CPU whilst indexing, but no other processes are being launched. At index contents, I'm seeing ffmpeg (~5 parallel processes, presumably generating thunbnails) but again no exiftool.

Looks consistent with 1), so once that is resolved this should be too.

3.

$ exiftool -S -GPSLatitude -GPSLongitude IMG_….jpg
GPSLatitude: 51 deg 28' 59.04" N
GPSLongitude: 0 deg 0' 37.54" W

Thanks! Based on 1) it doesn't seem to be a file issue, so let's get back to this if 1) doesn't resolve it.

[Terrance]

Bah, it took me until I'd written a quick Go program to confirm that couldn't find it either, to notice that I'd added the path wrong by including /usr/bin/vendor_perl/exiftool rather than /usr/bin/vendor_perl, sigh...

Ran the import again and looks like we're good!

[SmilyOrg]

Ah 😅 Glad you figured it out. Let me know how it works for you! (hmm, do we need a discord or something?)

[Terrance]

Somewhere to have more ad-hoc discussion might come in handy; raising issues can be a bit heavyweight for asking questions in what's ultimately an investigation rather than issue reporting. But ultimately it's up to you and how you prefer to engage with users. 🙂

[SmilyOrg]

Just created the most basic Discord server, feel free to join: https://discord.gg/8ntcnVYSxk

I'll add the link in the README and elsewhere later.