@Pokechu22: Commons Filter 303 operates on both anonymous and new users.

See also unactioned issue 320 at https://bitbucket.org/magnusmanske/flickr2commons/issues/320/doesnt-respond .

In T369298#9954690, @Urbanecm_WMF wrote:

Done.

Of course, the more contemporaneous errors continue to be reported on Commons.

I already removed the files, with now 22k pages on my watchlist. Since then, I have only had to back off to 700.

In T363622#9894181, @matej_suchanek wrote:

Something like https://commons.wikimedia.org/wiki/Special:ApiSandbox#action=watch&format=json&unwatch=1&generator=watchlistraw&formatversion=2&gwrnamespace=6&gwrlimit=500 can remove them in batches (of 500).

Thanks @Ladsgroup!

Yes, I have lots of crap on my Commons watchlist, built up over 17+ years. Based on a suggestion at https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump#Low_server_performance? after Special:EditWatchlist failed (see above), I tried to use https://commons.wikimedia.org/wiki/Special:EditWatchlist/raw and got "Not enough memory to open this page". :( How much memory should I need to edit my watchlist with 239k pages? Can someone rid my watchlist of all pages which start "File:" for me?

In T367172#9887919, @GhostInTheMachine wrote:

The status of the user at the moment they made the edit is the correct detail, not the status of the user now.

I had to back off to 100 today, and then I tried to edit my watchlist using https://commons.wikimedia.org/wiki/Special:EditWatchlist and got the following, so it looks like we need "Set $wgShowExceptionDetails = true;" on Commons:
MediaWiki internal error.
Original exception: [f497cc8d-d5a6-4ad1-95eb-db2be5de539e] 2024-06-13 13:19:30: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

Why is experience level important when displaying watchlist?

In edit https://commons.wikimedia.org/w/index.php?title=File:Queen_Victoria_by_Bassano.jpg&diff=prev&oldid=804669319 Cessy3 vandalistically added en caption "welcome". In edit https://commons.wikimedia.org/w/index.php?title=File:Queen_Victoria_by_Bassano.jpg&diff=prev&oldid=841293383 Haansn08 removed that caption, but earned abuse filter log entries https://commons.wikimedia.org/wiki/Special:AbuseLog/10343284 and https://commons.wikimedia.org/wiki/Special:AbuseLog/10343285 in the process because "New page wikitext, after the edit ($1) (new_wikitext)" is completely wrong (it is not wikitext at all, but a bastardized text representation of the change in wikibase-mediainfo) and triggered Commons Abuse Filter 58. Perhaps we can exclude changes where "New content model ($1) (new_content_model)" is 'wikibase-mediainfo' to remove such false positives?

Here is one of my configurations:

I had to back off to 500, 400, 300, 250, and then 200 today.

In T365154#9855369, @SDudley wrote:

What I end up doing when video2commons doesn't work is that I manually convert to webm on my own device using handbrake. It isn't a full proof alternative, but I guess it can work for a bit.

I had to back off to 400 again today.

In T363622#9750857, @Jeff_G wrote:

This happened intermittently. It didn't happen with suboptimal "limit=500".

In T365154#9809719, @Chicocvenancio wrote:

Clearly V2C is not ready for use, except for beta-testers.

@Yann I'm maintaining this on my free time and have made a grand total of 0 from all this work. This comment, as written, does not motivate me to work on this at all.

I got "An exception occurred: WorkerLostError: b'Worker exited prematurely: signal 15 (SIGTERM) Job: 4.'"

I have also gotten lie "No changes during the given period match these criteria." What can you do to make it faster or increase the timeout? What is the current timeout?

This happened intermittently. It didn't happen with suboptimal "limit=500".

In T295007#9655859, @Joe wrote:

With the API change, you should be able to upload by url large files (up to 4 GB IIRC) without incurring in timeouts; and that will also allow us to move file processing to Shellbox, making our infrastructure more secure.

In T355433#9485168, @MikhasikRV wrote:

In T355433#9484879, @Jeff_G wrote:

I was able to download the file as F 1-74-0217.PDF. In case one of us gets it to upload, what filename would you like and how would you like the file description page to read?

As I said in the other thread, this is not the only file I need to upload. But how did you manage to upload that file? Using Upload Wizard?

In T355433#9482093, @MatthewVernon wrote:

Right, those are all too far ago to still in the recent logs. Today's, however, I can find, and swift has done what was asked of it - that file was uploaded and subsequently deleted (before further requests got 404, which you'd expect after a successful delete).

In T355433#9482231, @MikhasikRV wrote:

@MatthewVernon I just used Upload Wizard to upload the file. I did not see neither attempt to delete the file after upload. After progressbar reached the end, it just spit out the abovementioned error.

You can try to upload the file yourself: https://fex.net/s/ckmb8ov - the same file or any other PDF bigger than 1.5 GB.

In T355433#9482934, @Wilfredor wrote:

I think the simplest way to correct this error is to lower the maximum upload limit to 1 GB for validation.

The thumbnails at https://commons.wikimedia.org/wiki/File:Ada_Health_Symptom_Checker_conceptual_overview.png are still broken. "via cp1111 cp1111, Varnish XID 376415587
Upstream caches: cp1111 int
Error: 500, Internal Server Error at Sat, 30 Dec 2023 11:49:56 GMT"

Another user has gotten "FAILED: stashfailed: Internal error: Server failed to store temporary file." - see edit https://commons.wikimedia.org/w/index.php?title=Commons:Help_desk&diff=prev&oldid=830516577 .

An hour later, it is responding.

See also the edits logged at https://commons.wikimedia.org/w/index.php?title=Special:AbuseLog&wpSearchUser=2605%3ABA00%3A4138%3A445%3A1974%3ACACD%3AE09D%3AA640&offset=&limit=50 and https://commons.wikimedia.org/w/index.php?title=Special:AbuseLog&wpSearchUser=Haansn08 .

See also the edits logged at https://commons.wikimedia.org/w/index.php?title=Special:AbuseLog&wpSearchUser=91.120.252.226 .

The full URLs for those example links are: https://commons.wikimedia.org/wiki/Special:AbuseLog/9710528 , https://commons.wikimedia.org/wiki/Special:AbuseLog/9711367 , and https://commons.wikimedia.org/wiki/Special:AbuseLog/9711938 . See also https://commons.wikimedia.org/wiki/Commons_talk:Abuse_filter#Report_by_Lieven , which will be archived to https://commons.wikimedia.org/wiki/Commons_talk:Abuse_filter/Archive_2023/04#Report_by_Lieven .

Affects Commons, too. :(

In T327003#8525400, @Ladsgroup wrote:

Wrapping should be fixable but making the link actually work (or any parsing of the wikitext to HTML) is quite hard without making the system vulnerable to Stored XSS attacks. I could use action=parse in the commons API but that wouldn't be useful if there is a template in source. It's a bit tricky to fix this.

This amounts to a request to increase the default $wgMaxArticleSize of 2048 (kilobytes) on production wikis. It was authored Feb 21 2006, 7:55 PM in rSVN13070 by timstarling (now @tstarling). Much has changed in user environments in the 16 years since then.

It happened again with edit https://commons.wikimedia.org/w/index.php?title=Commons:Help_desk&curid=523680&diff=698609678&oldid=698605975 00:49 24 October 2022 EDT -0400 (04:49 24 October 2022 UTC). Note also that there are three other edits to the Commons Help desk that falsely show as "updated since your last visit" too.

Here is how that 05:20, 23 October 2022 EDT -0400 (09:20, 23 October 2022 UTC) edit looks on my watchlist with grouping.

On the third hand, it did not happen with my next edit https://commons.wikimedia.org/w/index.php?title=Commons:Administrators%27_noticeboard/User_problems&diff=698405102&oldid=698403797 .

In T321277#8333277, @matmarex wrote:

Does this happen every time when replying with the reply tool, or just once or twice? And did it ever happen when not using the reply tool?

We couldn't reproduce it, and I noticed that there were recently a few new reports of pages not being marked as read on the watchlist when expected (see the last few comments on T218511). Most likely this is not related to the reply tool, and just a part of that general problem.

Same for en.wikipedia.beta.wmflabs.org.

How can file revisions go missing? Don't we have backups? Why can't we delete a file, even though one or more file revisions is missing? What can we do to prevent file revisions from going missing in the future, and to compensate for their missing status in the present?

On-wiki error report: https://commons.wikimedia.org/w/index.php?title=MediaWiki_talk:Gadget-AjaxQuickDelete.js/auto-errors&diff=prev&oldid=657064030
On-wiki discussion: https://commons.wikimedia.org/w/index.php?title=MediaWiki_talk:Gadget-AjaxQuickDelete.js#Renaming
This has been autoreported 11 times so far on https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-AjaxQuickDelete.js/auto-errors , starting "Wed, 18 May 2022 08:35:19 GMT".

In T288346#7283181, @AntiCompositeNumber wrote:

In T288346#7282921, @Krinkle wrote:

[...]
As such, perhaps it would make sense to codify that in MediaWiki natively that for NS_FILE we don't emit this event and instead assume it to be an upload (manually created pages there are very rare and usually an accident, and for catching/reviewing that we have recent changes already).

Would it be possible to only log filespace creations not associated with uploads? From a user's perspective, this wouldn't be too unexpected, as Special:Newpages already does that in the file namespace.

That would work for me. The consensus has now been archived to c:Commons:Village pump/Archive/2021/07#Page creation logs.

In T12331#7233358, @DonTrung wrote:

Should we create a separate task for Wikidata and Wikimedia Commons?

Another victim, this time at 6MB: https://commons.wikimedia.org/wiki/File:Age_of_sail_.jpg

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.

There are also 1,101 pages in https://commons.wikimedia.org/wiki/Category:User_talk_pages_where_template_include_size_is_exceeded .

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 289 pages and rising.

See also https://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/Vandalism/Archive_14#TRANSCODE_STATUS .

Another victim: https://commons.wikimedia.org/wiki/File:Jilemnick%C3%BD_h%C5%99bitov_Jind%C5%99ich_Ambro%C5%BE_n%C3%A1hrobek.jpg

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.

No tokens found. :(

Strangely, this is happening with my (proxied) Puffin Browser Pro, but not with Chrome, on the same iPad with the same connection.

In T222445#6162123, @WMDE-Fisch wrote:

@Meno25 @Helmoony @Jeff_G @Slowking4 it would be really great if we got some feedback on the above questions. We currently try to figure out what additional data would be helpful so that the communities can better deal with situations like this. Thanks! :-)

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.

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 45.33.139.173 via cp1086 frontend, Varnish XID 520356410
Upstream caches: cp1086 int
Error: 500, Internal Server Error at Sun, 01 Mar 2020 14:32:22 GMT

In T220828#5352582, @whym wrote:

Note to @Jeff_G: you might still see the bug on Commons, but that's expected. It might take some time before I update ArchiverBot@Commons to reflect the bug fix. (Maybe next weekend.)

In T12331#4320973, @kaldari wrote:

This is now live on all the wikis except Wikidata and Commons.

However, as of this diff 07:59, 14 July 2019 (UTC) it is still happening.