Okay, I see. My bad.

I see now that 157 OGG audio files at rowiki are identified as video, see https://ro.wikipedia.org/wiki/Special:Search/file:_local:_filetype:video_fileh:0.

Perfect, thanks. This can probably be closed then?

Thanks for your digging. I think you are right that a general fix is not necessary nor worthwhile to make so it'd be better just to repair this specific file individually. Do you know of any good tool that can repair it?

T282202: MediaViewer is unavailable for WebP originals

@matmarex Can you reproduce this?

@Jdlrobson But the problem arose along with the zooming and search bar issues, so it is very related indeed. Unless there was some very unlikely coincidence that the SVG edit button problem and the search bar/zooming problem arose at the exact same time independently of each other.

In T311795#8144017, @Jonteemil wrote:

Apart from the initial zooming and tiny search bar problem, we who are using the SVGedit tool are also affected by a third problem, namely the edit button when on SVG file pages, such as File:Test.svg is displayed incorrectly. An empty dropdown is shown eventhough the button hasn't been activated which should trigger the dropdown.

@DLynch Okay, so the bug should rather be reported on https://webkit.org/new-bug?

Apart from the initial zooming and tiny search bar problem, we who are using the SVGedit tool are also affected by a third problem, namely the edit button when on SVG file pages, such as File:Test.svg is displayed incorrectly. An empty dropdown is shown eventhough the button hasn't been activated which should trigger the dropdown.

@DLynch The screen recording is identical on Safari, Chrome and Firefox apps. Is it really possible that all three browsers have the exact same problem?

@DLynch Are you able to see the screen recording I uploaded?

@matmarex Can this be closed? It works as expected both on testwiki and enwiki now.

Are https://upload.wikimedia.org/wikipedia/commons/thumb/5/56/Christopher_Street_Day_Koeln_2022_033.webm/800px--Christopher_Street_Day_Koeln_2022_033.webm.jpg and https://upload.wikimedia.org/wikipedia/commons/thumb/5/56/Christopher_Street_Day_Koeln_2022_033.webm/320px--Christopher_Street_Day_Koeln_2022_033.webm.jpg supposed to display different images? (Which they do for me at least)

I'm not getting HTTP500. I am however getting another frame of the video than what is rendered as the JPG preview, which also seems weird.

@Tacsipacsi Aha, gotcha.

@matmarex I mean the prefixed colon is necessary. What isn't is the doubling of the pagename.

Okay, how can their info be updated in the search index then?

https://commons.wikimedia.org/wiki/Special:Search/filemime:audio/webm still lists a bunch of videos so this can't be fixed, or am I wrong?

I have resaved the smaller files using the CropTool which was a successful workaround but the ones with 100MB+ were to big so they still remain unrendered.

Okay, so to sum up, this is no Thumbor issue, but rather an issue with the GIF mimetype?

@Aklapper You think that's related?

@Krinkle You are listed as co-creator of GUC along with Luxo who is retired since 2014. Have you got the ability and time to fix this or know someone who might?

@NguoiDungKhongDinhDanh You're correct. I guess only enwiki and Commons are affected by this. Should still be fixed nonetheless.

I'm assuming https://commons.wikimedia.org/w/index.php?title=File%3AOBA_BiztKotv_CMYK_2011.tif also would be an example of a file affected by this bug.

Pinging @AntiCompositeNumber as always when I find strange files.

@jcrespo @AntiCompositeNumber Given that nothing has happened since october, should I just ask the uploaders or any user to reupload?

I figured this was a more precise title.

There are also DjVu and PDF files which possess the same issue, see https://commons.wikimedia.org/wiki/User:Jonteemil/sandbox2. Are they also unfixable except with reupload?

@TheDJ @brion Do you know what happened here? Was the work paused/discontinued?

@Aklapper I'll try remember to use the bug report form in the future. I can't seem to find any pattern, despite the fact that 99% of the files were uploaded by only two users. I wasn't sure about creating a task for this since I didn't know if the problem lied with Mediawiki or the files itself but @AntiCompositeNumber recommended a task be created to see if someone with Logstash access could see if there are any useful error logs.