This is expected behavior when there are network or backend errors. The interface is ugly, we didn't have time to make a proper error page yet (that would be https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/299 ). Apparently the server is returning a HTTP 500 when we request a thumbnail ("Error creating thumbnail: Error code: 137"); maybe the image is too big.

We should still show the metadata panel; that's a bug, but probably already fixed by https://gerrit.wikimedia.org/r/127384 (goes live this Thursday).

<img src="https://i.imgur.com/xWc7BCO.png"> Example for output in case of failure.

I recently discovered E:MultimediaViewer and installed it on all of my wikis - different OS, different VMs. All wikis show in about 25% of all images this problem, and I wonder, why you installed on Wikipedia this extension with such a bug (or potential bug).

Server logs show "file not found" in such cases.

Ctrl+F5 in the browser helps - the 1280(or other) pixel image is then rendered.

Let me know, if you need more details.

This bug is very annoying, pls. can you fix this with a high priority ?

This happens when thumbnails aren't ready...I think the reason it doesn't break in production is that thumb.php is our 404 handler for thumbnails.

https://www.mediawiki.org/wiki/Manual:Thumb.php#404_Handler

(In reply to Mark Holmquist from comment #4)

This happens when thumbnails aren't ready...I think the reason it doesn't
break in production is that thumb.php is our 404 handler for thumbnails.

Ah, a good point! Can you perhaps publish (here) the code for such a workaround?

"mid-air collision". thx

Should be documented in E:MultimediaViewer Installation (wiki and repo)

@mark: I will try to test this as soon as possible and report my results (later) here.

The image should be generated by the imageinfo API request AFAIK. Might try to set $wgMediaViewerUseThumbnailGuessing = false although in theory that should still work without a 404 handler, just less efficiently.

(In reply to Tisza Gergő from comment #10)

The image should be generated by the imageinfo API request AFAIK. Might try
to set $wgMediaViewerUseThumbnailGuessing = false although in theory that
should still work without a 404 handler, just less efficiently.

+1

Confirmed!

Your tip saved my live: setting this to false solved definitely all these problems on my servers.

Perhaps, the extension developers should set the default value as indicated by you to:

$wgMediaViewerUseThumbnailGuessing = false;

@Jean-Fred: you originally reported this bug. Please can you try the setting and then report here (and close the issue, if solved)?

@Tisza, @mark:
was my test and reply quick enough? ;-)

Do you have a public wiki where I could test this? I would still like to see how thumbnail guessing fails; it tries to load the image without making an API request (which will fail with certain wiki configurations, including the default one IIRC), but should fall back on the API request if it receives a 404, and that apparently did not work for your site.

(In reply to Tisza Gergő from comment #13)

Do you have a public wiki where I could test this?

Currently: I don't have any public wiki ready with the extension, but I can set up a my testwikis which run as wmflab instances. However, I am extremely short of time - will see what I can do in the next hours, or days.

I can say, the whole day, I had not a single failure on my big enterprise wikis any more, which is great news. In my view, you should simply set the default value to false.

(In reply to T. Gries from comment #14)

I can say, the whole day, I had not a single failure on my big enterprise
wikis any more, which is great news. In my view, you should simply set the
default value to false.

I will do that; still, if things don't work with it set to true, that means there is a bug in the code, or there is some possible condition that I did not take into account, and it would be nice to get to the bottom of that.

I can confirm, the default $wgMediaViewerUseThumbnailGuessing = true doesn't always work right if you don't have a 404 handler set up. Here's why: large sites probably *do* have caching set up (e.g. CloudFlare or Varnish), and the 404 will be cached, so the request after generation gets the cached 404. Whoops. This hurts everyone else who tries to access the cached file while the 404 is cached.

You could try adding no-cache headers to your second request; or if that is not possible, add a query parameter to the URL based on, say, the timestamp to break the cache for your backup request.

Also, Firefox is showing your two requests for the same image coming immediately in succession, with the call to imageinfo coming *after* both requests. In this situation, it will never work on the first view, even if caching is not an issue or you use cache-busting techniques. It needs to render the thumb first.

(In reply to Laurence 'GreenReaper' Parry from comment #16)

I can confirm, the default $wgMediaViewerUseThumbnailGuessing = true doesn't
always work right if you don't have a 404 handler set up. Here's why: large
sites probably *do* have caching set up (e.g. CloudFlare or Varnish), and
the 404 will be cached, so the request after generation gets the cached 404.
Whoops. This hurts everyone else who tries to access the cached file while
the 404 is cached.

Indeed, we ran into the same issue on Labs Beta recently (bug 67056).

You could try adding no-cache headers to your second request; or if that is
not possible, add a query parameter to the URL based on, say, the timestamp
to break the cache for your backup request.

Adding no-cache would defeat the point of thumbnail guessing, which is to shave off a few hundred milliseconds from the image loading time. (Plus, it would split frontend caches and increase their disk space usage significantly.) It's better to disable it by default then.

(In reply to Laurence 'GreenReaper' Parry from comment #17)

Also, Firefox is showing your two requests for the same image coming
immediately in succession, with the call to imageinfo coming *after* both
requests. In this situation, it will never work on the first view, even if
caching is not an issue or you use cache-busting techniques. It needs to
render the thumb first.

That's... complicated. We send an AJAX request for the image first, to get progress events and cache hit stats, fall back to a normal resource request if that doesn't work (due to crossorigin limitations, typically), fall back to imageinfo if even that doesn't work and send another request after the API call has finished.

There should probably be a flag to disable AJAX loading; it can be a problem with some setups, as in bug 62469

morbus wrote:

Random reporter from IRC. $wgMediaViewerUseThumbnailGuessing = false; works pretty well for me. In my case, I have no thumbs 404 handler (and, when the thumbnail didn't exist on the server, an .htaccess Rewrite rule would send the request back to Main_Page, confusing E:MultimediaViewer). After false'ing, my large images (>3 megs and over), which were causing the hiccups, are now all loading properly.

Adding no-cache would defeat the point of thumbnail guessing, which is
to shave off a few hundred milliseconds from the image loading time.

I think you missed the point - your second request *may get a 404* if you simply repeat it, even if the image _has_ been generated on the server by that point, because intermediate servers may cache the 404 for a short period of time.

The cache-busting on the second request for the thumbnail is intended to avoid this situation. Otherwise you get a big red message.

Change 142475 had a related patch set uploaded by Gergő Tisza:
Disable thumbnail URL guessing by default

https://gerrit.wikimedia.org/r/142475

Change 142476 had a related patch set uploaded by Gergő Tisza:
Keep thumbnail guessing enabled

https://gerrit.wikimedia.org/r/142476

(In reply to Laurence 'GreenReaper' Parry from comment #20)

I think you missed the point - your second request *may get a 404* if you
simply repeat it, even if the image _has_ been generated on the server by
that point, because intermediate servers may cache the 404 for a short
period of time.

There is no point in adding a workaround to thumbnail guessing which makes it slower than not using it in the first place - the whole point of the feature is to improve speed. For sites which have a CDN or reverse proxy, sending lots of requests which go around it will probably cause problems and/or be much slower. You should just not use thumbnail guessing in that case. (And if you care about speed, you should set up 404-handler-based thumbnail generation anyway.)

I think we've been misunderstanding each other, but it's my fault. :-)

What I was trying to say was that even when I set this variable to "false", there was an issue loading the image; it'd attempt to load twice in quick succession, failing both times, and only then make API calls. My belief was that this was the intended behaviour, and I was trying to suggest how it might be improved.

Having retested this, it seems that likely that I had cached resources which caused it to go down the "true" path even though I'd set it to "false". When I tried it again, having cleared everything out, it generated the image as expected.

Thanks for clearing that up!

Yeah, site-wide settings are passed via ResourceLoader which generates static .js files from them. I don't know the details of the caching strategy, but on WMF sites it's typically 5-10 minutes until a change takes effect.

Change 142476 merged by jenkins-bot:
Keep thumbnail guessing enabled

https://gerrit.wikimedia.org/r/142476

https://gerrit.wikimedia.org/r/#/c/142475/ still left here.

Change 142475 merged by jenkins-bot:
Disable thumbnail URL guessing by default

https://gerrit.wikimedia.org/r/142475

Change 154876 had a related patch set uploaded by Gergő Tisza:
Disable thumbnail URL guessing by default

https://gerrit.wikimedia.org/r/154876

Change 154876 merged by Gergő Tisza:
Disable thumbnail URL guessing by default

https://gerrit.wikimedia.org/r/154876

Merged and backported to 1.23. I think this takes care of all cases when this error appears, apart from genuine network errors, and maybe private wikis, but there is another ticket for that (bug 68522).