Page MenuHomePhabricator

Some ogg vorbis files fail transcode silently and have duration of 0
Closed, ResolvedPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

Examples:
https://commons.wikimedia.org/wiki/File:Segne_du,_Maria.mid
https://commons.wikimedia.org/wiki/File:POCAST_HARPIA.ogg
https://commons.wikimedia.org/wiki/File:Take_Me_Out_To_The_Ball_Game_-_Frankie_Masters_and_his_Orchestra.flac

What happens?:
These files are not properly playable, and fail to be transcoded. However once they fail, their entries in the transcode table are not registered as failing. This causes them to be 'in progress' forever and ever.

I tried re-enqueue these files (and many more) yesterday evening and they failed again. In the jobqueue, i can see that there were a bunch of retries of jobs, leading me to believe that the jobqueue can recognize them as failed, but

For a list of these look at https://quarry.wmcloud.org/query/100963
Ignore anything that was started in the last 3 hours or so, or that is a 1080p transcode.

What should have happened instead?:
The transcode should have been marked with transcode_time_error and transcode_error should contain the error output of the transcode process.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):

Event Timeline

Change #1226361 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/extensions/TimedMediaHandler@master] Fix 0 duration of certain ogg vorbis files

https://gerrit.wikimedia.org/r/1226361

Ogg vorbis issue: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TimedMediaHandler/+/1226361

Flac issue: T414641 https://github.com/wikimedia/getID3/pull/3

The midi case is interesting: https://commons.wikimedia.org/wiki/File:Segne_du,_Maria.mid

  1. It works from my local machine and when reuploaded to test wiki.
  2. it was previously deleted (a LONG time ago) and then restored due to 2026 PD day...
  3. it has not filled img_metadata in the image table

Same for https://commons.wikimedia.org/wiki/File:Honeysuckle_Rose_for_wikipedia.mid but PD day 2025
So these need their metadata force refreshed: T414642

Different are:
https://commons.wikimedia.org/wiki/File:Drum_note.mid
https://commons.wikimedia.org/wiki/File:Quick_note_midi.mid
https://commons.wikimedia.org/wiki/File:F_minor_chord.mid
which all run into the dividebyzero problem. It seems this is because getID3 doesnt support calculating the duration for files that have no tempo events. I think we can create some fallback logic for this. T414645

There's also a broke opus file: T414643 https://commons.wikimedia.org/wiki/File:Kp117-euxropa-unio.opus

Change #1226361 merged by jenkins-bot:

[mediawiki/extensions/TimedMediaHandler@master] Fix 0 duration of certain ogg vorbis files

https://gerrit.wikimedia.org/r/1226361

TheDJ renamed this task from Some midi, ogg and flac transcodes fail silently to Some ogg vorbis files fail transcode silently and have duration of 0.Jan 14 2026, 11:11 PM

After next week, i'll have to requeue the transcodes, so keeping this open for now.

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

run refreshImageMetadata --force --mediatype=AUDIO --mime="application/ogg" --metadata-contains="Stream Undecodable"

Seems that with media type pre filtering, a metadata contains filter is fast enough in this case (at least if the performance impact is similar enough to quarry)

Mentioned in SAL (#wikimedia-operations) [2026-02-05T09:49:42Z] <ammarpad@deploy2002> mwscript-k8s job started: refreshImageMetadata.php --wiki=commonswiki --mediatype=AUDIO --mime=application/ogg '--metadata-contains=Stream Undecodable' --force # T414348

It took around 3 minutes

NAME                       STATUS     COMPLETIONS   DURATION   AGE    SCRIPT
mw-script.codfw.q170xceo   Complete   1/1           3m15s      12m    refreshImageMetadata.php
TheDJ claimed this task.

Confirmed resolved. Thank you @Ammarpad !