Apr 6 2021
The third upload attempt (a retry with extra comment) completed.
The status of the checkbox appears to be dimmed only after the attempted upload starts.
I sometimes get sequences like the following, which is also concerning (indicating a stuck status for upwards of 30s):
00995: 11/86> in progress Upload: 100%
01110: 11/86> upload is stuck
01111: 11/86> Connection seems to be okay. Waiting one more time...
01115: 11/86> upload is stuck
01116: 11/86> Connection seems to be okay. Waiting one more time...
01120: 11/86> upload is stuck
01121: 11/86> Connection seems to be okay. Waiting one more time...
01125: 11/86> Chunk uploaded
The second attempt failed with stash 188ub70n674k.lpxppz.122116.webm and the following (trying again with the original formulation):
05171: 86/86> Server error 504 after uploading chunk:
Response: upstream request timeout
05171: 86/86> upload in progress Upload: 100%
05235: FAILED: internal_api_error_DBQueryError: [95e6982b-cd9d-4b4c-a124-ce7a1ca45c8b] Caught exception of type Wikimedia\Rdbms\DBQueryError
I tried to publish the file in my UploadStash anyway using a community tool, it said to try back tomorrow. I also started another upload of the same file with "use stash and async (recommended for large videos and photos)" unchecked, and I will check progress after I sleep.
Mar 27 2021
There are also 660 pages in https://commons.wikimedia.org/wiki/Category:User_talk_pages_where_template_include_size_is_exceeded .
Jan 28 2021
See also https://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard#Deletion_requests_issue . That section was archived to https://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/Archive_83#Deletion_requests_issue without further comment. https://commons.wikimedia.org/wiki/Category:Pages_where_template_include_size_is_exceeded stands at 252 pages and rising.
Jan 12 2021
Dec 6 2020
Nov 27 2020
Nov 19 2020
This appears to be happening again with https://commons.wikimedia.org/wiki/File:Standard_Model_of_Elementary_Particles_Euskaraz.jpg - please see https://commons.wikimedia.org/wiki/Commons:Help_desk#An_uploaded_image_can't_be_seen_at_any_given_wiki for details.
Oct 15 2020
Oct 12 2020
No tokens found. :(
Aug 3 2020
Jul 7 2020
Strangely, this is happening with my (proxied) Puffin Browser Pro, but not with Chrome, on the same iPad with the same connection.
Apr 9 2020
Mar 14 2020
This could be extended to all presentations of video thumbnails. See also https://commons.wikimedia.org/wiki/Commons:Help_desk#Changing_default_thumbnail_for_a_video.
Mar 1 2020
The discussion of the display of https://commons.wikimedia.org/wiki/File:Ambigram_New_York_Rich_Man.png was archived automatically to https://commons.wikimedia.org/wiki/Commons:Help_desk/Archive/2020/02#Thumbnail_doesn%27t_display and now I get the following:
Request from 22.214.171.124 via cp1086 frontend, Varnish XID 520356410
Upstream caches: cp1086 int
Error: 500, Internal Server Error at Sun, 01 Mar 2020 14:32:22 GMT
Feb 17 2020
Sep 11 2019
Jul 22 2019
Jul 14 2019
However, as of this diff 07:59, 14 July 2019 (UTC) it is still happening.
Jul 9 2019
Jul 5 2019
As of this diff 07:48, 3 July 2019 (UTC), it is thankfully no longer shuffling parameters on my user talk page on Commons.
Jun 22 2019
Jun 18 2019
It is still happening for me today. In the attached screenshot, I am "User:Jeff G." and my edit of 18:41 (UTC-4, EDT, 22:41 UTC with screenshot taken around 23:00 UTC) should have marked all the previous edits to c:Commons:Help desk as read, but it didn't.
May 3 2019
The problematic files included https://commons.wikimedia.org/w/index.php?title=File:Bareg5.jpg , https://commons.wikimedia.org/w/index.php?title=File:Toyota_Bus-Train_01.jpg , and https://commons.wikimedia.org/w/index.php?title=File:Toyota_Bus-Train_02.jpg ; all had to be deleted.
Apr 21 2019
A workaround is to start with [[Special:Log/block]] or https://commons.wikimedia.org/wiki/Special:Log/block instead.
Apr 2 2019
The same goes for https://tools.wmflabs.org/geocommons/ .
Mar 28 2019
Mar 25 2019
Mar 23 2019
Mar 22 2019
I found out in the past couple of days that when I unwatch and then watch a stubborn bolded page, that resolves the symptom for the current revision of that page better (with a higher success rate indistinguishable from 100%) than refreshing and purging. Of course, that is just a workaround and it doesn't scale.
Mar 20 2019
Mar 18 2019
This is also happening on Commons, see https://commons.wikimedia.org/wiki/Commons:Village_pump/Technical#Pages_visited_via_diff_remain_bolded .
Mar 12 2019
Mar 3 2019
Another example: https://commons.wikimedia.org/wiki/File:Miguel_Baptista_Benedict.jpg
Feb 15 2019
Can this tool please be configured to not import under 10 bytes file description page revisions, or at least to pad the ones under 10 bytes with spaces or the 10 byte string "Padded4AF4"? Alternatively, can it be configured to back off importation of revisions which fail any AF and import the rest (unless the latest revision fails)?
Feb 12 2019
Jan 31 2019
Jan 19 2019
Dec 29 2018
Sometimes, the rotation sought is not around the center point, but around the central vertical or horizontal axis (sometimes called mirroring, flipping, or flopping). This should be doable losslessly. See also c:MediaWiki talk:Gadget-RotateLink.js#Mirroring as Rotation.
Dec 20 2018
Nov 24 2018
Nov 19 2018
Sep 13 2018
Aug 3 2018
Finding and fixing the problem would be great; automating the restart would be a close second.
Jul 2 2018
Can you try putting it back as a test? How big was it?
Jul 1 2018
This has been happening on Commons, too. This edit by Bsadowski 1, who has Local user-groups Image reviewers, File movers, Rollbackers and Autoconfirmed users and Global user-group Stewards, appears unpatrolled in my watchlist. As a member of Image reviewers, that user should inherit the Autopatrolled group rights. https://commons.wikimedia.org/wiki/Special:ListGroupRights confirms that five groups have the right "Have one's own edits automatically marked as patrolled (autopatrol)": Image reviewers, Autopatrollers; Bots; Patrollers; and Administrators. See also https://commons.wikimedia.org/wiki/COM:VP#Unpatrolled rollbacks.
I suggest merge with T198449.
Jun 22 2018
Jun 6 2018
Jun 3 2018
May 31 2018
To be clear, by "same query", I meant https://tools.wmflabs.org/guc/?user=Krinkle&debug=true, currently "+38.09s: Quering wikis on s7.labsdb for matching revisions" out of "Total: 91.17s." with "Current time: Thu, 31 May 2018 04:00:09 +0000".
May 28 2018
I just did the same query and got "+110.24s: Quering wikis on s7.labsdb for matching revisions" out of "Total: 157.62s." with "Current time: Mon, 28 May 2018 13:14:28 +0000".
May 25 2018
Suggestions for the future:
- Don't use temporary names for tables which may become permanent.
- Name and describe tables appropriately, especially including those that have temporary names.
- Use invisible indexes for a while before actually dropping.
Apr 26 2018
Apr 23 2018
Apr 22 2018
No, this problem is not the same as in those other tickets. In this case, the image of Margaret Thatcher at https://upload.wikimedia.org/wikipedia/commons/thumb/9/92/Margaret_Thatcher_at_White_House.png/240px-Margaret_Thatcher_at_White_House.png looks significantly blurrier or more out of focus than the image of her at https://upload.wikimedia.org/wikipedia/commons/thumb/1/15/Margaret_Thatcher_at_White_House.jpg/240px-Margaret_Thatcher_at_White_House.jpg .
Mar 29 2018
Mar 21 2018
Mar 18 2018
Mar 14 2018
Mar 11 2018
Mar 6 2018
I am getting "Error: MySQL login data not found at", in addition to the originally reported warning.
Mar 5 2018
I mentioned this task at c:COM:VP#Files with too big wikitext. We need sanity checking on both Flickr2Commons and whatever it uses to upload.
Mar 3 2018
Feb 28 2018
If there is no other section, why do we even need this section header at all?
Feb 24 2018
Feb 22 2018
This would be especially helpful for IP Addresses.