Error initiating IA job

In which Wildbook did the issue occur? IoT

What operating system were you using? (eg. MacOS 10.15.3) MacOS 10.15.1

What web browser were you using? (eg. Chrome 79) Firefox 81.0.2

What is your role on the site? (admin, researcher, etc) Researcher

What happened? Start match and start new match all give error “error initiating IA job”

What did you expect to happen? Match results produced

What are some steps we could take to reproduce the issue? Looks like it was a server error that has been resolved on other platforms but maybe not on IoT?

If this is a bulk import report, send the spreadsheet to services@wildme.org with the email subject line matching your bug report

Hi Jillian,

I’ve received a similar report via email but will need example encounters to fully diagnose.
Can you provide links to some or all of the affected encounters?

Thanks!

@colin,

Here is a link to one of mine: https://iot.wildbook.org/encounters/encounter.jsp?number=8b974614-0d00-4a15-8130-347d19144b43

1 Like

here are two other examples:

1 Like

Hello

Still having the same issue today. Here are 2 more examples:


Hi Jillian,

We are working on this issue today and will hopefully have an update for you soon.

Thanks.

Hi Jillian and Jo,

I’ve tracked down the cause of the failing ID jobs you both notified me about. The culprit was some unsupported .tiff type image files. When these were part of a matching set, the job would fail. Since a matching set is constructed based on species, location and viewpoint this caused certain jobs to fail every time and others to continue to be successful.

I’ve tracked down the images in the system so they are turned ‘off’ and will never be added to the matching process. I believe they are all ORP images added during bulk import. Here is a list of them if you would like to delete those images and add ones in JPG format that can be used for ID:

’9.11.14 Turtle reef L.tiff’
’9.11.14 turtle reef R .tiff’
GR375_160110_RIGHT_10.01.16.tiff
GR755_160605_R.tiff
’HK1151_141010 L.tiff’
’HK1151_141023 L.tiff’
’HK1151_141023 R.tiff’
’HK2002_141101 L.tiff’
’HK2002_141101 R.tiff’
’HK2053_141021 L.tiff’
’HK2053_141021 R.tiff’
HK2054_141027_L.tiff
HK2054_141027_R.tiff
HK2356_170127_R.tiff
HK2365_160114_LEFT_14.01.16.tiff
HK287_150510_LEFT100515.tiff
HK321_151129_LEFT_29.11.15.tiff
’HK368_140825 L.tiff’
’Male Left Turtle reef 9.11.14.tiff’

I’ve run eight test matching jobs at this point with no errors so you should be good to continue
running ID in the meantime.

Thanks.

Hi Colin

All of those images have been deleted except:
’9.11.14 Turtle reef L.tiff’
’9.11.14 turtle reef R .tiff’
’Male Left Turtle reef 9.11.14.tiff’

I’m not sure these photos are associated with an encounter. I think they are unidentified photos sent in the first batch I sent a long time ago that were not referenced on a metadata sheet. These can be deleted. Thanks!

Following up

I just ran a few matches from Lhaviyani atoll and I’m still getting the same error. Mostly on the right profile for hawksbill turtles. Here are the examples





Hi Jillian,

I just ran new ID jobs on several of these assets and they completed successfully with returned results.
Perhaps the .tiff file references were cached somewhere. I’ve restarted the server as an extra step to flush them if this is the case.

Here’s a couple links to results I received on encounters you linked above:



Note that these links will be invalid if a new matching job is run for one of the query images.

Please let me know if these are working for you now. Thanks!

Thanks, Colin. They appear to be working now

However, when I ran a new matching job… I got the error again. It still seems to be the hawksbill in Lhaviyani that are giving the error (but not all of them). Am I doing something wrong?

Hi Jillian,

It doesn’t seem like you are doing anything wrong. One of the bad files, or even just it’s name must have been still held in memory somewhere.

I’ve done some new work on to IOT to prevent any new .tiff images from being added to IOT, upgraded the platform to the very latest code on our core branch and restarted the server again.

After this the examples you provided above seem to be producing normal ID results. Please let me know if you have any more trouble with this.

Thanks!