Page MenuHomePhabricator

Score audio player vanishes after a few seconds, then gets replaced by another one
Closed, ResolvedPublic


Reported in :

  1. Firefox 59 on Linux, being logged in
  2. Go to
  3. See a black audio player with this code:
<audio id="mwe_player_2" preload="none" style="width: 300px;" class="kskin" data-disablecontrols="options,timedText"><source src="//" type="audio/ogg; codecs=&quot;vorbis&quot;"></audio>
  1. After a few seconds, the audio player disappears.
  2. A little bit later, the previous audio player is replaced by a grey one:
<div class="mediaContainer" style="width:300px"><div class="mwPlayerContainer k-player" style="width: 300px; position: relative; height: 20px;"> ...

Not really FUOC, probably some script executed late?

Event Timeline

TheDJ subscribed.

Known problems with our old player.

The better question... why does it take so long to initialise the player ?

Gut feeling tells me it might be because it takes long to read the metadata from the media file. Maybe not using an ogg skeleton index or something similar problematic.

It might be due to the audio not being as a MediaWiki UnregisteredFile (or more appropriate class) and using FSFileBackend. As a test of this hypothesis, when override_audio is set, it does not take long, suggesting it is a(nother) problem with using TimedMediaTransformOutput, which takes the URL of the file. It is not caused by the fix to T148716, as the scores do take significantly longer than proper files when both are on the same page. Correct me if I've got to a false conclusion however.

(Note: I didn't notice your edit before I submitted this comment)

TMH causes such headaches... I don't have much time these days to examine this problem sadly, but I hope that interoperability between these two extensions improve. I might get to it when freer.

About the length of the audio, it is read off a metadata file, of which I am trying to reduce the use of. It is not being read by Skeleton for each request. That bug was already filed: T49533 (why we use the metadata file here)

Ebe123 triaged this task as High priority.May 28 2018, 8:21 PM

Change 449628 had a related patch set uploaded (by Ebe123; owner: Ebe123):
[mediawiki/extensions/Score@master] Use different MIME type for OGG files

Change 449628 merged by jenkins-bot:
[mediawiki/extensions/Score@master] Use different MIME type for OGG files

Ebe123 added a project: Regression.

FYI, it's application/ogg, because that is the filetype. And when originally this stuff was added, it was impossible to reliably detect if an ogg file was audio or video. For this reason it was stored in the database as the agnostic application/ogg. The audio/video determination was added later. Also the audio, video aliases were only registered in 2008, application/ogg was better supported for a couple more years these new mime types were introduced.