There should probably be a min-height for this..

Multichannel opus audio was allegedly fixed upstream in Safari this week.

confirmed fixed

@Albacore60 Cannot reproduce:

Concerns could be:

1. the mime type mismatch of the thumbmime field of the api handler example request
2. I'd be slightly concerned with webp support on uncommon devices like ereaders, but difficult to get insight on that..

In T410807#11662504, @AAlhazwani-WMF wrote:

In T410807#11661780, @Mormegil wrote:

on this feeling scary: this email is sent immediately after someone removes their email address from the project. so in most cases, the recipient has just performed this action, so the context should make it clear and not alarming. if someone receives this email without having taken that action, the stronger wording is actually helpful because it prompts them to investigate right away - which could signal that their account may have been compromised.

it seems to work reliably for me right now.

In T390256#11648947, @WebcompatApple wrote:

@TheDJ Do you remember which issues triggered this fixViewportForTabletDevices()? I could double check on the side of WebKit.

We are just waiting for upstream to make a new release with php 8.5 compatibility as well

In T416247#11635809, @Szmenderowiecki wrote:

Two weeks have gone by, how this is going?

Can someone please review my last changes to the TMH patch ?
I'd like to get that thing off the board finally.

This was fixed with https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TimedMediaHandler/+/997938

This is much less common nowadays. While it still happens occasionally to a file, the systematic problem is solved. Remaining problems have known causes with separate issues that keep track of the progress on those.

This is intentional and by design

Can @Pppery or a phab admin please edit the comments to link to those pastes with the huge lists, instead of transcluding them ? This ticket can hardly even render anymore on my machines due to the size of those..

hmm. why are these new columns not available in quarry ? maintain views seems to not have anything specific for this table as far as I can see... does the cookbook simply have to be run for it to be aware ?

Calling this fixed.

In T148047#11603814, @Jdlrobson-WMF wrote:

I was talking to @cscott about this today.
@CDanis enabling lazy loaded images on desktop in Parsoid would reduce requests for thumbnails across the site, reduces HTML processing time on mobile (which currently uses DOM parsing) and be an improvement for users so would likely also be popular with SRE. Currently the mobile version of Parsoid supports native lazy loading via MobileFrontend.

Not as grafana metrics or anything like that (other than the job queue counts)

I think this actually recovered now, because of all the fixes we made recently to the transcode queue processing. This was obfuscating the numbers, but also kept hosts pre-occupied because they didn't realize their job had actually already ended.

@Draceane this is not a MediaWiki or WMF problem. This is a problem in the tool of a community member. The tool extracts part of the page and reuses that. That makes it very vulnerable to problems like this.

I've been looking a bit at logstash, and I can't see any significant change within the noise that is already there. I did notice that upload.wikimedia.org came up quote often as a CSP violation but this was a pre existing situation and I'm not entirely sure what is causing that. It's also for png etc, but the reporting url seems to be a proper wikimedia source that is I open it doesn't report any violation errors whatsoever.

This tiff does have some interesting aspects that make them identifiable (according to exiftool)

I’m assuming this is iOS you are showing ? Still cannot reproduce unfortunately. Could be for a multitude of reasons of course.

Screenshot of the article London on English Wikipedia, where it works in mobile view on a tablet. Can you please be more exact in your report ?

I've looked into jpeg xl a bit. First of all it is not supported by getID3. So we either need to make an implementation inside getID3 or we have to create our own parser.

Did you refresh the page before every measurement you did? because otherwise you can't know if your numbers are effected by cache or not.

i restarted the transcodes for the affected files

"don't worry about performance" is not a carte blanche to exploit the resources made available nor a directive that WMF has to fix a problem.

Confirmed resolved. Thank you @Ammarpad !

In T117618#11585450, @Bawolff wrote:

when CSP is in enforce mode I would expect only the CSP error, if its in report-only I would expect both. When i tested right now, no CSP header was served with the file.

In T270855#11572020, @Adpocalyptic wrote:

Is there a specific page you can link to where I might be able to try testing consensus on a proposed 'main format' like this? Or atleast make the case/pitch the idea of everything being on JXL by default or converted into it.

In T414645#11585721, @mb wrote:

The files mentioned in the OP are very short. However, there are many much longer files that also show a zero duration

@Met4lGod76 @ShivaanshSingh and @Akaza24 thank you all for reporting back and working on this problem. As you might have noticed, we ended up with multiple reports and 3!! patch submissions for this, and I picked the one that I though was most ready to merge. The next patch release of 1.45 should fix this problem for all Postgres users.

There's also an issue with audio transcodes, that will require backport.

Closing this in favor of the separate tickets T414645 (midi) and T414641 (flac)

This extension should be upgraded to use the newer abstract schema changes system, then this shouldn't be a problem as the system will use the correct type for the database platform.

Yeah, rev_timestamp should be added to the select of that query

This will require backporting

Duplicate with T414599

The last DivisionByZero of this code path was on Jan 23, 2026 @ 21:30:51.475 UTC

Example file:
https://test.wikipedia.org/wiki/File:18KOZ.pdf
https://upload.wikimedia.org/wikipedia/test/b/b5/18KOZ.pdf

313 Audio files (on Commons, the other wikis might have a few as well) that will have to be force refreshed: https://quarry.wmcloud.org/query/101759

doesnt this depend on the links that WE have/use to get to them? In that case, we can analyze our https to http external link ratio, sample the http bucket to discover percentage of just dead links and wed have an idea of how many links this would practically even impact.
Id be surprised if its more than .5% for enwp and more than 1% for commons

Another example: https://www.mediawiki.org/wiki/Extension:SyntaxHighlight

Considering this fixed

Should only error with that option enabled indeed, which wikimedia does not yet use. Problem was that in some situations we indeed do not have clientWidth, but we do already have a width set. So i modified that condition to only override if needed.

Works as intended for Safari. Opens fullsize and allows subtitle rendering, software decoding of videos on older devices and custom controls.

BTW. I think I completed this change, so if someone can review, that would be appreciated.

Ive seen cases where a file was deleted but a program still had a pointer to the deleted file (programming error). The file would not show up in the file listing and even in du counts, but the OS could not yet free the disk space either.

It does a straight $file->transform(), which indeed has this effect of creating a thumbnail according to the specified instructions. There are other entrypoints that should apply the correct logic before deciding to do a transform. Not sure which is the most appropriate one of the top of my head.

FYI, it seems the HebMorph developers/maintainers made the solution commercial and they are no longer improving the open source version.
I'm removing upstream for that reason.

We merged a less invasive fix in https://gerrit.wikimedia.org/r/1229723

The upstream report seems to have partially been merged in https://github.com/citixensas/drf-friendly-errors/pull/4
Not sure if that fixes it.