Last modified: 2011-04-05 01:36:36 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2888 - Broken thumbnails not being generated
Broken thumbnails not being generated
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.6.x
PC Windows XP
: Highest major with 9 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 7598
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-18 02:33 UTC by David Benbennick
Modified: 2011-04-05 01:36 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description David Benbennick 2005-07-18 02:33:23 UTC
See 
http://commons.wikimedia.org/wiki/Category:Colorado_county_locator_maps 
for example.  At the moment, four of the images in the category 
have broken thumbnails, though the full-size image displays fine.
Comment 1 David Benbennick 2005-07-23 23:27:07 UTC
The problem seems to have been fixed.  I re-uploaded all of the images I 
was aware of with broken thumbnails.  The new thumbnails that were 
generated are fine now. 
Comment 2 David Benbennick 2005-08-10 05:28:17 UTC
I'm reopening this bug.  I've been seeing the same error a lot lately, and I'm 
getting tired of re-uploading images. 
 
It would be okay if MediaWiki failed to generate thumbnails when the servers 
are overloaded.  It could be smart about it: don't try to generate the same 
thumbnail for a half hour, say.  But at the moment, MediaWiki produces 
incorrect thumbnails, and doesn't detect the error.  The only way to get it to 
re-generate the broken thumbnails is to re-upload the image, which is not a 
good solution. 
 
See, for example, 
 
http://commons.wikimedia.org/wiki/Category:Colorado_wilderness_area_maps 
 
At the moment, 3 of 9 entries in the category are just vertical lines. 
Comment 3 Rob Church 2005-12-19 07:38:48 UTC
Is this still an issue, given the recent upgrades and performance tweaks
regarding images and image servers, etc?
Comment 4 David Benbennick 2005-12-19 16:26:58 UTC
I haven't seen the problem lately.  I went ahead and set this to FIXED; I'll
reopen it if the problem pops up again.
Comment 5 David Benbennick 2005-12-19 16:33:17 UTC
The thumbnail displayed at
http://en.wikipedia.org/wiki/Image:Map_of_Eagle_County%2C_Colorado.png
(if you're logged out!) is broken.
Comment 6 Invalid Account 2006-02-08 18:08:30 UTC
We seem to be suffering from this bug at the yoyowiki:
http://www.yoyowiki.org/index.php/Special:Newimages

It seems to be limited to .jpg files, or at least .gif files are unaffected. We
can post images in pages with a frame, just not with a thumbnail or you simply
end up with a vertical line. Help would be appreciated.
Comment 7 Invalid Account 2006-02-08 18:09:12 UTC
We seem to be suffering from this bug at the yoyowiki:
http://www.yoyowiki.org/index.php/Special:Newimages

It seems to be limited to .jpg files, or at least .gif files are unaffected. We
can post images in pages with a frame, just not with a thumbnail or you simply
end up with a vertical line. Help would be appreciated.
Comment 8 David Benbennick 2006-03-06 15:24:58 UTC
I'm pushing up the severity on this bug, since the problems have been happening
more and more lately.  For example, the 94 pixel thumbnail of
[[Image:Schwingende Saiten.png]] is blank, and the 761px thumbnail of
[[Image:Map of Eagle County, Colorado.png]] is a green line, though the map
displays fine at [[Eagle County, Colorado]].

Presumably MediaWiki's installation of ImageMagick is broken.
Comment 9 Brion Vibber 2006-03-06 21:04:35 UTC
Let me guess, they're very large images, especially PNGs or progressive JPEGs.
This hits the memory limit we've set to keep them from bringing down the servers.
Comment 10 David Benbennick 2006-03-06 21:18:39 UTC
Well, there's no need to guess.  You can see for yourself that the first example
is 38KB, and the second is 55KB.  The problem isn't that MediaWiki can't
thumbnail these images at all.  For example, the 95px thumbnail of
[[Image:Schwingende Saiten.png]], and the 760px thumbnail of
[[Image:Map of Eagle County, Colorado.png]], are fine.  The problem seems to be
that from time to time, randomly, MediaWiki produces broken thumbnails.  And the
only way to make MediaWiki throw away a broken thumbnail and try again is to
re-upload the image.
Comment 11 Brion Vibber 2006-03-06 22:25:46 UTC
It's not the compressed size, it's the *uncompressed* size.

X pixels times Y pixels times Z color depth == lots of memory
Comment 12 Brion Vibber 2006-03-06 22:26:16 UTC
Oh, and you don't have to reupload the image. Use ?action=purge on the image page. 
(If it's a Commons image, do that *ON COMMONS*.)
Comment 13 David Benbennick 2006-03-06 23:16:05 UTC
(In reply to comment #11)
> It's not the compressed size, it's the *uncompressed* size.
> 
> X pixels times Y pixels times Z color depth == lots of memory

Well, the first example is 9.1 megapixels, and the second is 8.4 Mpixels.  There
is, of course, the 12.5 Mpixel hard limit for PNG images, but neither of these
images is affected by that.

Thanks for the hint about action=purge.  After using it about 10 times, I
managed to get it so that all of the relevant thumbnails of [[Image:Map of Eagle
County, Colorado.png]] were non-broken.  (The relevant thumbnail sizes being the
ones selectable in the preferences.)  Of course, that situation will only last
until someone else purges the thumbnails, and MediaWiki produces more broken ones.

So action=purge isn't much of a workaround.  A much better solution would
involve first figuring out why MediaWiki is producing broken thumbnails. 
Perhaps the convert command is getting killed before it finishes?  If so, then
it should be possible to just delete broken thumbnails as they are produced, so
they don't hang around and cause trouble.
Comment 14 Brion Vibber 2006-03-07 00:10:23 UTC
We set a runtime memory limit, as I already stated.
Comment 15 David Benbennick 2006-03-07 00:21:09 UTC
Okay, perhaps that runtime memory limit is what is causing the broken thumbnails
to be generated.  Any thoughts on how to fix the problem?
Comment 16 brianna.laugher 2006-06-08 03:40:47 UTC
Is this what is causing so many SVGs, especially produced by Adobe Illustrator,
to have broken thumbnails?

http://commons.wikimedia.org/wiki/Commons:Help_desk#SVG_problem

Is there anything at all that can be done to avoid this problem?
Comment 17 Nux 2006-11-03 00:03:38 UTC
There seems to be something more to it then just a memory limit. And the image
below is not a progressive JPG so thats not it either.

Have a look at:
http://commons.wikimedia.org/wiki/Image_talk:FordFiesta6.jpg
You may see that every thumb of Image:FordFiesta6.jpg is fine (including 179px)
except for the one that is 180px (which is also a default one).

I've tried purging few times and CTRL+R on the thumb but none if this works. I
thought it will get generated but a day have passed and the thumb is still
missing so it looks like something more permanent.

It looks like the thumb got broken on upload of the image and it just stays that
way.
Comment 18 Duja 2006-11-07 07:54:14 UTC
Same thing for http://commons.wikimedia.org/wiki/Image_talk:Serbia mountain
ranges.png. It appears on 201 and 199, but not on 200 px.

[[en:User:Duja]]
Comment 19 Nux 2006-11-08 00:37:36 UTC
It seams like it's happening more often and happens not only on loading the
first version of an image. See:
http://commons.wikimedia.org/wiki/Image_talk:Bl%C3%BCcher.jpg
were you can find _previous_ version of the current (colored) image. I've
already tried purging and even reuploading but the thumbs remain black&white.

Could it be that this is related to creation of the Wikimedia logo mosaic (about
400 unique images now)?
Comment 20 Nux 2006-12-03 01:49:12 UTC
There is a workaround for the issue which seems to work every time. Just use
link like this:
http://commons.wikimedia.org/w/thumb.php?action=purge&f=file_name.ext&w=250
where file_name.ext is file name with extension
and 250 is a thumb size to refresh

So I guess it WORKSFORME, but not sure if all would agree.
Comment 21 Nicolas Brouard 2007-03-15 11:43:49 UTC
(In reply to comment #20)
> There is a workaround for the issue which seems to work every time. Just use
> link like this:
> http://commons.wikimedia.org/w/thumb.php?action=purge&f=file_name.ext&w=250
> where file_name.ext is file name with extension
> and 250 is a thumb size to refresh
> 
> So I guess it WORKSFORME, but not sure if all would agree.

This doesn't seems to work:
http://commons.wikimedia.org/w/thumb.php?action=purge&f=Foucault-rotz.gif&w=300
will give you the answer 

Although this PHP script (/w/thumb.php) exists, the file requested for output
(/mnt/upload3/wikipedia/commons/thumb/8/82/Foucault-rotz.gif/300px-Foucault-rotz.gif)
does not.

Changing 'rotz' with 'anim' will work. It is true that the convert uses more
memory and time with 'rotz' where the space is rotated than with 'anim'. But on
my machine, the command 
<pre>
/usr/bin/convert -background white -size 300
/var/www/html/foo/w/images/8/82/Foucault-rotz.gif -coalesce -thumbnail 300x225!
-depth 8
/var/www/html/foo/w/images/thumb/8/82/Foucault-rotz.gif/300px-Foucault-rotz.gif
</pre>
works and needs 2 minutes to achieve. The size of the thumb
300px-Foucault-rotz.gif is 374364.

How can I upload it whith the already uploaded generic name Foucault-rotz.gif? 

See [[wp:fr:Pendule de Foucault]] if you are interested in knowing why 2 graphs
are needed for better comprehension.
Comment 22 Andrew Hancock 2007-03-30 12:05:34 UTC
I'm having this same problem with the images on the [[Maps of Japan]] page. In
addition some of the full size images are not available because of a server
cache error. See my post on the
[[Commons:Village_pump#Thumbnails_and_large_version_problem|Village pump]] for a
full description.
Comment 23 Handige Harry 2007-05-10 20:01:53 UTC
Not sure whether I am reporting the same problem, but my Finnish friend Para says that it 
is. Sometimes an SVG produces in some sizes an incorrect PNG and a correct one in other 
sizes. The incorrect PNG may be an obsolete version (for example 
http://commons.wikimedia.org/wiki/Image:BSicon_MWEXlfrfu.svg) but it can also be a 
completely different picture which never existed as a previous version (for example 
http://commons.wikimedia.org/wiki/Image:BSicon dSTRe.svg.
The problem cannot be solved with action=purge. Uploading the picture again does not solve 
the problem either. Para suggested to use: 
http://upload.wikimedia.org/wikipedia/commons/thumb/e/e7/BSicon_MWEXlfrfu.svg/500px-
BSicon_MWEXlfrfu.svg.pngsomearbitrarycharacters and this solves the problem, but (in this 
case) for 500px only. Handige Harry ~~~~
Comment 24 Matthew Flaschen 2007-12-27 06:46:55 UTC
I have also noticed that SVGs do not always rerender when you upload a new version.  The problem is difficult to reproduce, but purging does not appear to fix the issue.
Comment 25 Matthew Flaschen 2007-12-27 06:52:19 UTC
I can confirm that the random character workaround (http://upload.wikimedia.org/wikipedia/commons/thumb/c/cb/Latin_U.svg/500px-Latin_U.svg.pngsadf)  worked on http://commons.wikimedia.org/w/index.php?title=Image:Latin_U.svg .  Purging did not, which I believe is a bug.
Comment 26 Bryan Tong Minh 2011-03-12 20:16:09 UTC
If convert processes get killed, do they produce 0-byte files? If they do, the bad files should be removed by the thumbnailing code.
Comment 27 Mark A. Hershberger 2011-04-05 01:36:36 UTC
Closing this since we think it has been fixed (re bug triage meeting).  Please re-open with an example if you think it isn't fixed.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links