[Jupiter]500 Error when facet by type image

[sfarnel]

Describe the bug
When attempting to facet across all ERA items by type Image, a 500 error is returned.

To Reproduce
Steps to reproduce the behavior:

1. Go to ERA home page
2. Click on Search to retrieve all items
3. Scroll down to Item Type Filter
4. Click on Image
5. A 500 error is returned

Expected behavior
One would expect a result list of all ERA items of type Image.

Screenshots

Desktop (please complete the following information):

• OS: Windows
• Browser and Version: Chrome Version 74.0.3729.131 (Official Build) (64-bit), Firefox Version 74.0.3729.131 (Official Build) (64-bit)

[pgwillia]

I did a little investigation. There is an item with an image that's "not an image". I'm not sure which item it is, but rollbar could help us triangulate. https://rollbar.com/ualbertalib/jupiter/items/647/?item_page=1&#instances

[pgwillia]

Can use search.json to help narrow down.

It's this one! https://era.library.ualberta.ca/items/f1c4404a-f946-4077-8356-572b5cc10b0a

id | "f1c4404a-f946-4077-8356-572b5cc10b0a"
-- | --
title | "01 First of series of views of children playing at constructing a tent in town near houses - Nunavut (NWT)-1447"
doi | "doi:10.7939/R3RF5KF6T"
creators |  
0 | "Halpern, Joel Martin"
created | "1983/08/01"
description | null

[sfarnel]

Interesting; thanks @pgwillia! Interestingly, if you try and navigate to the Halpern collection (which this item is from) you get the same error, so it must be that image. @pbinkley @weiweishi is there any way to see if we can get the object from OpenStack to see if it's corrupted? The original dvds may be in the vault if we need to go that far back.

[pbinkley]

the file is not a jpeg.

$ identify 87_102c.jpg 
identify: Not a JPEG file: starts with 0xef 0xbf `87_102c.jpg' @ error/jpeg.c/JPEGErrorHandler/340.

I'll see if we have a good copy in Swift.

[pbinkley]

I've confirmed that the file in the old Fedora 3 repo (wolves) has the same SHA1 checksum as the file in Jupiter (48c88c0c7638cfb5de2cdd2dde76b98b33ad0e52), so it must have been corrupt when we got it.

[pbinkley]

Conclusion: we need a new image from source.

[mbarnett]

actual crashes are at long last fixed, tracking the possibility of getting a non-corrupt copy of that file over on #898