Pictures upload failing when creating a new observation via web browser

Is anyone still experiencing the problem described in the first post? If so, it would be helpful to get more information like:

  • What operating system are you using, and what version?
  • What web browser are you using and what version?

If there are any updates to your OS or browser I’d recommend applying them and trying again. If you are still having the problem and are willing to spend some time working with me to investigate it, please direct message me.

This is out of scope of this bug report, but I’d recommend never uploading more than about 50 photos at one time. We’ve considered adding a hard limit, but haven’t done that yet.

2 Likes

I previously reported this issue but I was able to upload as usual from this machine/browser/OS so it looks like it’s been fixed for me, thank you

1 Like

@pleary @tiwane Ugh I spoke too soon :(

The issue occurs in all browsers (Chrome, Safari, Firefox) on Mac OS 12.5.1. I reproduced it on another laptop running 12.5. My connectivity seems to be working fine otherwise, I have (up) 200.49 Mbps / (down) 33.20 Mbps via a wireless router, no firewall / proxy / port restriction configured on my network, and I am able to download and upload photos on other websites just fine (including the screenshot above).

@pleary DM’ing you.

I wrote an email on Sep 8 reporting this error and Tony Iwane directed me to this forum post, unfortunately I’ve been caught up with university stuff (just started) and haven’t been able to leave a reply or explain my case in detail. I’m on Windows 10 Home and I use Firefox, which I think is updated. I also tried in Chrome and got the same error.
I experienced it with multiple pictures last time I uploaded, the next day I uploaded the files to a blank observation that I had made, and it worked as usual.
Today I was uploading and this time it only happened with 3 files; 2 out of those 3 have a warning when opened on the Photos app of my PC, it reads; “Sorry, Photos can’t open this file because the format is currently unsupported, or the file is corrupted.” I’m not sure why I’m getting this, but the first time I experienced the iNaturalist error I don’t recall getting such a warning on the Photos app.

I tried to reupload the file that isn’t corrupted and it worked as usual.

iNatupload3

This image took 57 attempts before it suddenly “worked”. I also tried cloning the same photo 100 times and dragging them all in. On average, 6/100 worked and the others were “insta-rejected” by the site.

It must be some weird connection thing. Is there a very short window for a lost connection to “time out” and just give up? As far as I know my connection is not bad at all and I’ve never had any interruption issues elsewhere, but I don’t see how else this could happen. The fact there is no real trend and it’s seemingly random must correlate to some amount of site use x internet connection of the PC.

Seems to be the same problem as my post here:
https://forum.inaturalist.org/t/retry-uploads-on-the-browser-uploader/34628/3

I’m having the same issue as jmartin54. Using a MacBook Pro and Safari. Haven’t been able to upload images since the server issues at iNaturalist. Just attempted to upload 12 images. All twelve appeared as expected on the page; all but two “disappeared” from the page.

are the files that you’re uploading coming directly from your computer? or are they coming from device connected by USB? or are they coming off of a cloud storage service? if cloud, which one? (it looks like you might be using 2 different ones.)

does it make a difference if you select the files from the file selector rather than dragging and dropping them into the browser window?

It makes no difference whether I drag the files from an alternative storage (USB, cloud, dropbox) or natively from file explorer on my computer. I have tried various methods.

Just joining this thread as I’ve been having the same issue and feel like it started sometime midsummer (possibly as late as August as well). Extremely frustrating and frequently takes 3-4X the amount of time to upload some observations these days. Interestingly, if I click in the “Species name” field on one of those failed uploads, it tends to still offer appropriate species identifications, so there is visual information getting through, but as noted above, it may take several attempts to get the observation to upload cleanly.

in one of these cases, have you ever tried to submit the observation anyway, even though it seemed like the image file was not loaded properly? (if so, when the observation is submitted, do you end up with an image on the observation?)

UPDATE: nevermind. i know the answer. if i block the POST /photos request to force this kind of error (or if i disable my connection to the browser prior to adding a photo to the upload screen), i will be able to still get computer vision suggestions as you noted (and i will still get a timestamp added to the observation from the image file metadata), but the submitted observation will lack the photo.

(i also tried letting the POST complete, just blocking the download of the image saved to iNat servers after the POST is complete, but that doesn’t produce the same kind of error as folks are noting here.)

(one little oddity here is that the POST request is to /photos rather than /v1/photos. i guess it doesn’t really matter. i assume they would both route to the same final destination, since the request is being sent with the JWT in the header. it just seems a little inconsistent not to go the /v1/photos route here.)

which OS and browser are you using? are you using any kind of ad blocker or other extension on your browser?

Yes, as you noted, the computer vision suggestions are there, but if I carry through with the post, the photo does not appear.
I am using Chrome on an HP PC, and the same thing happens from my Lenovo (also through Chrome). The only extension I have running is Google Scholar.
I almost always do some cropping, using whatever the default photo editor that comes with Windows 10, but today posted some trail cam photos directly from the SD card and had the same issue- only one out of four non-manipulated images made it. Puzzling.

if you open the Developer Tools in Chrome and look for error messages in the console when an observation photo fails to load, do you find any console error messages? if so, what do they say?

is one of these PCs a laptop? if so, can you try loading photos on a different internet connection and see if you still encounter the same issues on a different ISP?

1 Like

I’ll assess both of those with my next upload- stay tuned! I won’t be in a space with a different ISP until Tuesday.
Stan

1 Like

Well after several months of struggling with uploads, the issue seems to have resolved itself. Other than upgrading my OS to Ventura as soon as it was available as a general release, I haven’t changed anything on my end. It actually has been working fine for several weeks now, but I was afraid I would jinx it if I said anything. lol. Anyways, thanks for looking into the issue and thanks to whoever/whatever changed to resolve my issue.

2 Likes


Been happening to me for the last few months, very frustrating and makes me not want to observe anything. I’m using Firefox and Windows 11. Problem occurs when photos are dragged and dropped or when I select “choose files.”

if you open the developer tools in your browser, do you see any error messages logged in the console?

The one that seems to be labeled an “error” says “Loading the Google Maps JavaScript API without a callback is not supported: https://developers.google.com/maps/documentation/javascript/url-params#required_parameters

Also there are three that are called “warnings” rather than “errors”

that should be something else.

warnings shouldn’t matter.

have the console open while you drag a photo into the upload screen. when you get the red exclamation point on the upload card, is there anything new in the console?

There is a new warning:
Deprecation warning: value provided is not in a recognized RFC2822 or ISO format. moment construction falls back to js Date(), which is not reliable across all browsers and versions. Non RFC2822/ISO date formats are discouraged. Please refer to http://momentjs.com/guides/#/warnings/js-date/ for more info.