Page MenuHomePhabricator

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

Description

Reported in https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#score :

  1. Firefox 59 on Linux, being logged in
  2. Go to https://de.wikipedia.org/wiki/Kontrapunkt?usedebug=true#Doppelter_und_mehrfacher_Kontrapunkt
  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="//upload.wikimedia.org/score/4/6/467jvcxmm842fmh7gjqsluoyc7c0f0t/467jvcxm.ogg" 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

Aklapper created this task.Apr 19 2018, 1:59 PM
TheDJ added a subscriber: TheDJ.

Known problems with our old player.

TheDJ added a comment.EditedApr 19 2018, 3:11 PM

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.

Ebe123 added a subscriber: Ebe123.EditedApr 19 2018, 8:34 PM

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.

Ebe123 added a comment.EditedApr 19 2018, 8:52 PM

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

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

Ebe123 claimed this task.Aug 1 2018, 1:20 AM

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

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

Ebe123 closed this task as Resolved.Aug 1 2018, 2:40 AM
Ebe123 added a project: Regression.
TheDJ added a comment.Aug 1 2018, 8:21 AM

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.