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

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. :(((

This has been open for 5 months!!! Could someone please take care of it? Thanks, Yann

Hi, I got several of these errors this morning (CET) while accessing pages on Commons: https://commons.wikimedia.org/wiki/Commons:Undeletion_requests/Current_requests

MediaWiki internal error.

it happened again now with https://commons.wikimedia.org/w/index.php?title=File:Le_247%C3%A8me_r%C3%A9giment_d%27infanterie_et_son_porte-drapeau,_le_servannais_Alexandre_Miniac,_durant_la_Grande_Guerre..jpg&action=submit

[eb4a7b76-e0ab-4a1c-9899-d1682f15831f] 2025-03-13 12:19:50: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError"

In T341007#10579276, @MatthewVernon wrote:

I looked for the first of those two files (sudo cumin -x --force --no-progress --no-color -o txt O:swift::proxy "grep -F '1blqxup05ci8.bvryzz.1.png' /var/log/swift/proxy-access.log") and I find no error codes in the ~125 hits. Broadly, there's a series of PUTs (all of which return 201), then a series of GETs (all of which return 200), then a series of DELETEs (all of which return 204); for objects with names like 1blqxup05ci8.bvryzz.1.png.2 So AFAICT, swift did what it was told, and something higher in the stack uploaded a bunch of fragments, did something with them and then deleted them all.

Why do you think this was a recurrence of the error you reported in 2023?

It worked after I disabled https://commons.wikimedia.org/w/index.php?title=User:The_Photographer/QICvote.js

I got again this error while trying to upload a big PNG file using https://commons.wikimedia.org/wiki/User:Rillke/bigChunkedUpload.js.
Chrome console:

Failed to load resource: the server responded with a status of 403 ()Understand this errorAI
File:Adams_Synchronological_Chart,_1881.png:1 Refused to execute script from 'https://commons.wikimedia.org/w/index.php?title=User:The_Photographer/QICvote.js&action=raw&ctype=text/javascript' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.Understand this errorAI
index.php?action=raw&ctype=text/javascript&title=User:Rillke/MwJSBot.js&_=2:1136 mwbot> stashfailed: Could not store upload in the stash (UploadStashFileException): "An unknown error occurred in storage backend "local-swift-eqiad".". Object success Object

Same error message for a 2.42 GB video:

03452: finalize/127> Still waiting for server to rebuild uploaded file
03457: finalize/127> Still waiting for server to rebuild uploaded file
03462: FAILED: stashfailed: Could not store upload in the stash (UploadStashFileException): "An unknown error occurred in storage backend "local-swift-eqiad".".

I am not sure, but I don't think so.

Now for the 5th time:

Request from 89.248.174.2 via cp3067 cp3067, Varnish XID 1041959184
Error: 503, Backend fetch failed at Wed, 01 Jan 2025 14:11:11 GMT

Hi, I got this error several times while merging big files (deleting, undeleting, and reverting): https://commons.wikimedia.org/wiki/File:Why_Be_Good_(1929)_by_William_A._Seiter.webm
3 times, and it still fails.

Request from 89.248.174.2 via cp3067 cp3067, Varnish XID 937264010
Error: 503, Backend fetch failed at Wed, 01 Jan 2025 11:52:41 GMT

I got this error because there was previously a file by that name, now moved to another name. As an admin, I should be able to upload over a deleted file.
https://archive.org/details/filmdailyvolume11112newy

Internal error: MediaWiki\Status\StatusFormatter::getWikiText called for a good result, this is incorrect

Same with https://commons.wikimedia.org/wiki/File:Air-France_Madame._Invitation_au_voyage_num%C3%A9ro_39_-_D%C3%A9pliant_publicitaire_-_photographies,_Henri_Cartier-Bresson,_Burri,_A.F._-_btv1b10102329m_(08_of_13).jpg
Deleted only after 4 tries:

[2ab32948-3b20-4ed9-9eae-2c676457b561] 2024-12-23 13:41:37: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

This happened again while trying to upload a new version of https://commons.wikimedia.org/wiki/File:The_Lion_of_the_Moguls_-_Le_Lion_des_Mogols_(1924)_dir._Jean_Epstein.webm

04369: finalize/189> Still waiting for server to publish uploaded file
04374: FAILED: stashfailed: An unknown error occurred in storage backend "local-swift-codfw".

Hi, Thanks for answering. As mentioned in the task description, Description files are available too: append .txt to the URLs. This includes categories. Please ask me if there are any more questions.

Yes, I uploaded it OK today.

I checked again today, and from a fast DSL connection, uploading to Internet Archive is about 10 faster than to Wikimedia Commons (10 MB/s vs. 1 MB/s). This concerns big videos (2 to 3 GB), which I upload with Rillke chunked upload tool: https://commons.wikimedia.org/wiki/User:Rillke/bigChunkedUpload.js
I usually use https://speedify.com/ so my IP is in the Netherlands, but it is quite the same without it. It seems that IA has the same bandwidth for upload and download, while Wikimedia has a reduced bandwidth for upload.

This has been opened for a month, and still no answer. Please process this task.

Now with another file, I got

Again after the last chunk :(((

Well, I expect such requests to be fulfilled after a week or so. I am quite surprised that it is still not done after 3 weeks. Thanks, Tann

This has been open for 3 weeks now. Could you please process it? Thanks,

This has been open for 2 weeks now. Could you please process it? Thanks,

May I know how long this will take? Thanks,

Duplicate.

Hi, I used the link on https://video2commons.toolforge.org/ : https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?title=Server+side+upload+for+Yann&projects=Wikimedia-Site-requests%2Ccommons%2Cvideo2commons%2Cserver-side-upload-request&description=Please+upload+these+file(s)+to+Wikimedia+Commons%3A%0A%0A**URLs**%0A%0A*+https%3A%2F%2Fvideo2commons.toolforge.org%2Fstatic%2Fssu%2FRock%2C_Rock%2C_Rock!_(1956)_by_Will_Price.webm%0A*+https%3A%2F%2Fvideo2commons.toolforge.org%2Fstatic%2Fssu%2FThe_Man_with_the_Golden_Arm_(1955)_by_Otto_Preminger.webm%0A%0A%2F%2FDescription+files+are+available+too%3A+append+%60.txt%60+to+the+URLs.%2F%2F%0A%0A**Checksums**%0A%0A%7C+**File**+%7C+**MD5**+%7C%0A%7C+Rock%2C_Rock%2C_Rock!_(1956)_by_Will_Price.webm+%7C+a35312815438950666fc92a854cde5c9+%7C%0A%7C+The_Man_with_the_Golden_Arm_(1955)_by_Otto_Preminger.webm+%7C+39f6f4a5b0e9944ef7fd10eb15427c58+%7C%0A%0AThank+you!

And now, while editing https://commons.wikimedia.org/w/index.php?title=Commons:Featured_picture_candidates/File:Calaveras_of_day_of_the_dead_in_mexico.jpg&action=submit

https://commons.wikimedia.org/w/index.php?title=File:Reserve_Bank_of_Zimbabwe_5_Dollars_2019_obseve.jpg can't be undeleted due to this bug:

Again with https://commons.wikimedia.org/wiki/File:Ricardo_Monastero_1.png

Idem here: https://commons.wikimedia.org/wiki/File:Indium.jpg