Hi, Sorry, but this bug is completely random. It appears somewhere sometimes, and then disappears.

Still happening. New PDF files show 0 x 0 pixels upon upload, or after a purge. A second (or third) purge seems to fix the problem.

This looks similar to T107664 and T298417

In T434358#12211593, @Aklapper wrote:

https://en.wikisource.org/wiki/Index:Eddington_-_Stellar_Movements_and_the_Structure_of_the_Universe,_1914.pdf says
Source file must be fixed before proofreading

While https://en.wikisource.org/wiki/File:Eddington_-_Stellar_Movements_and_the_Structure_of_the_Universe,_1914.pdf renders for me.

But where exactly on which page am I supposed to see "Failed to initialize OpenSeadragon, no image found." ? A screenshot would be welcome.

And this one ? https://en.wikisource.org/wiki/Index:Eddington_-_Stellar_Movements_and_the_Structure_of_the_Universe,_1914.pdf

This was reported before in T356510 and T333746, but closed as Invalid.

Purge on en.ws fixes the problem. But while it is required after most uploads?

New example here: https://en.wikisource.org/wiki/File:Proceedings_of_the_fifth_International_congress_of_mathematicians,_Cambridge,_part_2,_1912.pdf
The file seems to be OK on Commons, but doesn't display on Wikisource with the message

Failed to initialize OpenSeadragon, no image found.

on https://en.wikisource.org/w/index.php?title=Page:Proceedings_of_the_fifth_International_congress_of_mathematicians,_Cambridge,_part_2,_1912.pdf/11&action=edit&redlink=1

Similar to T420341

Similar to T297942. So this issue exists for around 5 years!!!

Similar to T297942

Re everyone else, i appreciate people are frustrated, but tons of "pls fix" comments distract from the comments with useful information about the causes of the bug.

Now no image loads in this work: https://en.wikisource.org/wiki/Index:Works_of_Gustave_Flaubert,_vol._2,_Madame_Bovary.pdf

Same error as above in https://en.wikisource.org/wiki/Page:Works_of_Michael_de_Montaigne,_Hurd_and_Houghton,_1866,_vol._1.pdf/33

Right now, images do not appear in https://en.wikisource.org/wiki/Page:Works_of_Gustave_Flaubert,_vol._2,_Madame_Bovary.pdf/240 and https://en.wikisource.org/wiki/Page:Works_of_Gustave_Flaubert,_vol._2,_Madame_Bovary.pdf/242

In T420341#12134512, @MGA73 wrote:

The OpenSeadragon-issue i mentioned Sun, Jul 12, 4:12 PM seems to be gone now. I do not know if the patch above did it or what happend. But I had a few other files with issues and they all seem to work fine now.

https://commons.wikimedia.org/wiki/File:Works_of_Michael_de_Montaigne,_Hurd_and_Houghton,_1866,_vol._2.pdf is a weird case. Thumbnail was shown after upload. Then it disappeared after purging. Then it reappeared after 2-3 purges. Then it disappeared again when trying to use it on Wikisource.

In T420341#12112946, @Bawolff wrote:

"Failed to initialize OpenSeadragon ...".

That error is presumably coming from a gadget or toolforge. Please keep separate issues to separate bugs unless it is clear they have the same root cause.

This is exactly the same as T190260

Again now, same error message from https://commons.wikimedia.org/w/index.php?title=Special:UploadStash&withJS=MediaWiki:EnhancedStash.js

Now https://commons.wikimedia.org/w/index.php?title=Special:UploadStash&withJS=MediaWiki:EnhancedStash.js works.

Isn't this similar to T299521?

Isn't this similar to T420341?

This is still happening, and very annoying. It seems nothing has been done for over 2 months.
I have recently uploaded some big PDF files, and they systematically have this issue.
Thumbnails appear after 2 to 10 purges (!!!) depending on the file size. Please look at this bug.

Actually, the issue seems to be independent of uploading files. Just looking at https://commons.wikimedia.org/w/index.php?title=Special:UploadStash&withJS=MediaWiki:EnhancedStash.js produces

The maximum request time of 60 sec. was exceeded.
[657be3d2-357b-4970-8038-bed311f8f486] 2026-07-05 09:34:51: Fatal exception of type "Wikimedia\RequestTimeout\RequestTimeoutException"

And again with another file:

00625: finalize/70> Still waiting for server to rebuild uploaded file
00629: finalize/70> Still waiting for server to rebuild uploaded file
00634: FAILED: uploadstash-file-not-found: Key "1crui87o6ma0.ak495n.1.pdf" not found in stash.

And

[acaea699-d856-4605-b365-5211f5d5384f] 2026-07-05 07:59:53: Fatal exception of type "RuntimeException"

However I have successfully uploaded such files recently:
https://commons.wikimedia.org/wiki/File:The_Sketch_-_A_journal_of_art_and_actuality,_vol._24,_1898-1899.pdf

OK, but the question is: How much space saved if the files were compressed?

The best solution would be to compress automatically on upload, and decompress on download. I think that demand from TIFF files is not so important to create on burden on the servers.

I am curious. What is the average size of these files? And how much storage would be saved if compressed?

Ah OK, so these proposed deletions are not like usual deletions where the content is still in the database, but hidden to non-admin users?

Hi, I don't understand why you want to delete these talk pages. Now that they exist, I don't see the point.

Actually, a PDF can never have 0 x 0 pixels. It cannot exist. So whenever Mediawiki gets 0 x 0 pixels, something is wrong somewhere. Now if the PDF is faulty, Mediawiki should send a message saying so, but I have never seen this case on Commons or any other Wikimedia project (while it is rare, I got such a case today locally with qpdf).

Yes, I agree with GPSLeo. We had a working setup, why was it deliberately broken? We can't welcome manually thousands of users. The change should be reverted until a proper patch is implemented.

How do you explain the change of behaviour of Wikimedia_Commons_Welcome after the change of welcoming policy?

Hi, Many new users on Commons do not get a welcome message, after after editing (I added the message manually):
https://commons.wikimedia.org/wiki/User_talk:Eduardpetrovsky
https://commons.wikimedia.org/wiki/User_talk:AlejandroUB
https://commons.wikimedia.org/wiki/User_talk:TOSSOU_Eb%C3%A9n%C3%A9z%C3%A8re
https://commons.wikimedia.org/wiki/User_talk:Afiqilyasakmal
https://commons.wikimedia.org/wiki/User_talk:Dr.Deepak_Vikhe
https://commons.wikimedia.org/wiki/User_talk:Oglocx_mindart
https://commons.wikimedia.org/wiki/User_talk:Karwankuje11
https://commons.wikimedia.org/wiki/User_talk:Mariellamillan
https://commons.wikimedia.org/wiki/User_talk:Lizzieliette
https://commons.wikimedia.org/wiki/User_talk:Juliaconisbee
https://commons.wikimedia.org/wiki/User_talk:Impactfulupcomingleaders
etc., etc.

Trying to summarize the issue:

For this file https://en.wikisource.org/wiki/File:Pepita_Jimenez_(1886).pdf purge works on Commons, but the file fails to display properly on Wikisource, even after several purges. This was reported by several users, i.e. https://en.wikisource.org/wiki/Wikisource:Scriptorium#Failed_to_initialize_OpenSeadragon_(again)

OK, some big files show 0 x 0 upon upload (even after purging), but display is OK after some time.

This bug causes also weird caching issues: https://commons.wikimedia.org/wiki/File:Das_Mikroskop_in_der_Toxikologie;_Beitr%C3%A4ge_zur_mikroskopischen_und_mikrochemischen_Diagnostik_der_wichtigsten_Metall-_und_Pflanzengifte,_f%C3%BCr_Gerichts%C3%A4rzte_(IA_dasmikroskopind00helwgoog).pdf
The version from 18:39, 6 May 2026 is OK but can't be displayed, and other versions are all wrong.

Reported by several users on Commons: https://commons.wikimedia.org/wiki/Commons:Village_pump#'Too_many_requests:_please_respect_our_robot_policy'

And now the dummy file trick doesn't work anymore. This is becoming nasty.
https://commons.wikimedia.org/wiki/File:Gandhi_-_The_Story_of_My_Experiments_With_Truth,_vol._1.pdf

Again:

• https://commons.wikimedia.org/wiki/File:Aanden_i_naturen_(IA_aandeninaturen00rsgoog).pdf
• https://commons.wikimedia.org/wiki/File:A%E1%B9%9Bajnord-_awetaranakan_ekeghets%CA%BBwoh_andamnerun_-_or_k%C4%9B_kh%C5%8Dsi_Hayastaneayts%CA%BB_..._(IA_aajnordawetaran01unkngoog).pdf
• https://commons.wikimedia.org/wiki/File:Bulletin_de_la_soci%C3%A9t%C3%A9_des_bibliophiles_bretons_et_de_l%27histoire_de_Bretagne_(8e_ann%C3%A9e),_1885.pdf

Thumbnails do not display despite multiple purges. These are small files, so "too much time and too much memory" is surprising. Please fix this bug. Beside Commons, it affects Wikisource greatly.

Historically ?action=purge would re-trigger metadata extraction, but that was removed. As a first step i would suggest bringing that back.

Again here https://commons.wikimedia.org/wiki/File:Daubi%C3%A9_-_La_Femme_pauvre_au_dix-neuvi%C3%A8me_si%C3%A8cle,_1870,_tome_1.pdf

In T420341#11806156, @Bawolff wrote:

0x0 means that metadata was failed to be extracted, which probably means it takes too much time or too much memory

Indeed, this file displays 0 × 0 pixels on WS even with repeated purges: https://en.wikisource.org/wiki/File:Dangerous_Drugs_(Special_Preventive_Measures)_Act_1985.pdf

As other people have reported, the problem is increasing. Many files which were OK at the time of upload have now a problem. See screenshot.

For https://commons.wikimedia.org/w/index.php?title=File:DepEd_Undersecretary_Michael_T._Poa.jpg
I get

(Cannot access the database: Cannot access the database: Database servers in cluster30 are overloaded. In order to protect application servers, the circuit breaking to databases of this section have been activated. Please try again a few seconds.)

Again https://commons.wikimedia.org/wiki/File:Lucas_-_Recherches_sur_l%27analyse_ind%C3%A9termin%C3%A9e_et_l%27arithm%C3%A9tique_de_Diophante,_1873.pdf

Here is an example of a persistent issue, no matter what I do: https://commons.wikimedia.org/wiki/File:Gide_-_Le_Journal_des_Faux-monnayeurs.pdf
And it is a small file, so the issue is not the size.

In T420341#11747982, @Yann wrote:

This issue seems to have disappeared. Any change lately?

It failed again, this time with

02180: finalize/83> Still waiting for server to rebuild uploaded file
02185: finalize/83> Still waiting for server to rebuild uploaded file
02190: FAILED: stashfailed: Internal error: Server failed to store temporary file.

Purging the PDF seems to fix the issue.

This issue seems to have disappeared. Any change lately?

This issue seems to have disappeared.

Purge didn't work here: https://en.wikisource.org/wiki/File:Land_and_Liberty,_Vol._20_-_1919.pdf (383 MB).

This happens to all PDF files, but if the files are not too big, a simple purge fixes the issue.

• https://commons.wikimedia.org/wiki/File:Annales_de_chimie_et_de_physique,_tome_28,_1913.pdf (purge is sufficient, 248 MB)
• https://commons.wikimedia.org/wiki/File:Annales_de_chimie,_tome_5-6,_1790.pdf (purge doesn't work, uploading a dummy file solves the issue, 425 MB)

I hope this helps.

The file uploaded fine on the second try: https://commons.wikimedia.org/wiki/File:Annales_de_chimie%2C_Tome_43%2C_1802.pdf

Again
https://commons.wikimedia.org/wiki/File:Annales_de_chimie%2C_Tome_2%2C_1789.pdf
https://commons.wikimedia.org/wiki/File:Annales_de_chimie%2C_Tome_3%2C_1789.pdf

Again here https://commons.wikimedia.org/wiki/File:Annales_de_chimie,_Tome_1,_1789.pdf

It happened again, so this seems to be systematic and reproductible. I have opened a new report: T420341

I has happened twice to me recently. I uploaded a dummy file, and reverted to the original, and it fixed the issue.
https://commons.wikimedia.org/wiki/File:Annales_de_chimie,_tome_13-14,_1792.pdf
https://commons.wikimedia.org/wiki/File:Annales_de_chimie,_tome_11-12,_1791-1792.pdf

Actually there was a previous version, so the issue is not really important. https://upload.wikimedia.org/wikipedia/commons/7/7a/Canadian_National_Vimy_Memorial.JPG
I guess there is a cache issue now.

I think I found a way to fix that. Saving in with baseline instead of progressive, and then there is no display issue even with 1423.52 Megapixels: https://commons.wikimedia.org/wiki/File:Rembrandt_-_The_Abduction_of_Europa_-_Google_Art_Project.jpg

Wow, great! Thanks to you all!

Also https://commons.wikimedia.org/wiki/File:India_and_adjacent_countries,_1917.jpg
https://commons.wikimedia.org/wiki/File:India_and_adjacent_countries,_1907_(13441003).jpg and https://commons.wikimedia.org/wiki/File:1915_India_and_Adjacent_Countries_by_Survey_of_India.jpg

Same error from other big files: https://commons.wikimedia.org/wiki/File:India_and_adjacent_countries,_1917.jpg
https://commons.wikimedia.org/wiki/File:India_and_adjacent_countries,_1907_(13441003).jpg and https://commons.wikimedia.org/wiki/File:1915_India_and_Adjacent_Countries_by_Survey_of_India.jpg
Should I open another report? It looks like identical to me.

Two more:
https://commons.wikimedia.org/wiki/File:Album_%C3%89tienne-Jules_Marey_CDF_13Fi3.pdf
https://commons.wikimedia.org/wiki/File:Jameson_-_Montesquieu_et_l%27esclavage.pdf

And also https://commons.wikimedia.org/w/index.php?title=Commons_talk:Character_copyrights&curid=144415052&diff=1028956209&oldid=1028940977

[8c470d23-ba02-4803-b03b-f0129380febb] 2025-05-06 21:12:18: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError"

Same as my post above: https://commons.wikimedia.org/wiki/File:Vincent_van_Gogh_-_La_Chambre_%C3%A0_coucher_-_Google_Art_Project,_Amsterdam.jpg
Temporarily reducing size to 20,000 × 15,869 pixels, 317.38 Megapixels, makes it works.

https://commons.wikimedia.org/wiki/File:Rembrandt_-_The_Abduction_of_Europa_-_Google_Art_Project.jpg thumbnails failed, but https://commons.wikimedia.org/wiki/File:Rembrandt_Harmensz._van_Rijn_-_The_Abduction_of_Europa_-_Google_Art_Project.jpg OK. Same resolution: 30,000 × 23,413 pixels, 702.39 Megapixels

In T392348#10758260, @AntiCompositeNumber wrote:

This file likely exceeds the Debian-provided resource limits for ImageMagick. It seems like it's failing fast, so it's likely exceeding them on load rather than while attempting to render the thumbnail. T220171: Generate thumbnails of large JPGs with VIPS is the solution.

In T236446#10728543, @dbenjaminmiller wrote:

The notion that YouTube videos must be converted to a free format is a misconception. YouTube already prefers VP9/Opus in WebM as its delivery format. Also, YouTube Premium, though it allows downloading of videos, doesn't allow for them to be downloaded as files on the user's filesystem, whereas yt-dlp does. So those two points aren't material.

What we need is MediaWiki doing the conversion from MP4 to a free format. For downloading and uploading, we can use upload-by-url which already exists. It allows uploading from a white list, so we can deny such websites which forbid using yt-dlp.

In T378451#10725665, @Don-vip wrote:

Sorry it's me who deleted the files to ensure they were not filling the disks and making V2C completely unavailable like in May 2024. I was unaware they were related to this ticket. Large files are not supposed to remain this long. If no one actually hanlde these requests in a reasonible delay, I'll have to delete the functionality from V2C to avoid false hopes.

I don't know why V2C requests a SSU, but if it does, it is not possible to upload these files in any other way. So all this work is lost. :(((