Thu, Nov 7
Note that a Promise polyfill can be loaded at the cost of a few kb of compat code, but there's so many other reasons to want to deprecate IE 11 and to move to newer JS versions and most of the other things can't be polyfilled so easily.
Mon, Oct 21
I have some more diagnostic info on T235934 for what appears to be the same problem (installing mobilefrontend). Workaround is to manually clone extensions/MobileFrontend and re-run vagrant provision.
Fri, Oct 18
Yeah, looks like it's dying in the same place over on that one.
Thu, Oct 17
Tue, Oct 15
Oct 10 2019
Sounds like some of that sequence resulted in a conflict that didn't get handled well at the time. Following the error message back to the code symptom, the case is this in LocalFileRestoreBatch.php:
Oct 2 2019
Sep 26 2019
I've updated the documentation at https://www.mediawiki.org/wiki/MediaWiki-Vagrant to link to this bug report and mention that you can manually log in with vagrant ssh and run mwscript maintenance/changePassword.php --user=Admin --password=vagrant to set the initial password.
Sep 24 2019
Haven't encountered this in a while; Comcast etc may have improved the intermediate routes. Closing out as resolved.
Sep 19 2019
Looks like the audio wasn't getting initialized at the right time (how did it work on iOS? no clue!) unless mwEmbedSupport has already been loaded.
Sep 17 2019
Sep 11 2019
Looks like in PHP 7.2 the empty string gets interned to a special shared instance (zend_empty_string)... It's possible something's corrupting zend_empty_string, either its contents or its hash (h) field. If we can get a core dump it should be possible to inspect the symbol...
Aug 28 2019
Aug 21 2019
I'm still not sure I can reliably tell the difference but I trust you. :) Titles being sometimes late by random amounts up to 250ms seems like it would make sense given the poor latency guarantees on the timeupdate event, so I'm not sure there's much we can do directly here...
Aug 20 2019
Could this be latency from the timeupdate event? It can trigger with a wait as long as 250ms between events per spec.
Aug 14 2019
Note the parser cache key is not available to the hook. Fun!
I think default mode is checked because there's a separate pcache suffix for folks using the beta-mode -- this is targeted at clearing the non-beta-mode entries after a site-config switch.
The only POSTs I see in there are in setContainerAccess, addMissingHashMetadata, and doDescribeInternal, which all update existing files. Could be there's a hole in the logic of one of them that's dropping Content-Type, or that some files were missing it to begin with but it was being filled in on high-level fetches, or something, so they worked until something updated the data?
Hmm, I notice this in SwiftFileBackend.php:
Great, I'll tidy up this patch in a bit (once I get the subtitle lazy-loading patched back in) and we'll worry about lazy-loading later.
Since AFAIK extensions are meant to use wikipage.content for setup, I think any area where wikitext features are expected to work _should_ trigger the hook... A common class name would still require knowing when to run setup, and potentially one might want to update the indicator (what happens during edit preview?). So we either have to add a second hook that does the same thing as wikipage.content but is explicitly scoped to non-primary areas, or ...? Hmm, bears further thought.
For a video that triggers player setup but hasn't actually been played, in Chrome/Firefox where no ogv.js shim is needed, they seem to weigh in (as reported from mw.inspect, so uncompressed) at around 293 KiB for MwEmbed+jquery.ui and 288 KiB for video.js with the core.min.js variant.
Or... perhaps MW should run wikipage.content against the contents of <indicator> as well?
Looking at the TimedMediaHandler JS, it uses the wikipage.content hook which passes a jQuery object holding the content area in which to process elements. Anything outside the content area is not processed.
Can you create a copy of the template that uses the form that fails? I'm uncertain what to modify from the description.
Aug 12 2019
Would you want to trim in the base handling of the metadata, or in the output API serialization specifically? Might be best to do it all around if we're going to apply such rounding in ways that are machine-readable.
Patch switches to the core distribution (no http-streaming component) and the more aggressively pre-minified version. Not quite complete, as this means we can't patch in the text track lazy-loading on top as easily.
Aug 9 2019
This seems to be during a chunked upload of an Ogg audio or video file. Any chance we can get the original file chunks?
I can repro the inconsistency on both domains. I think it's a HHVM vs Zend PHP difference; the shorter serialization is served from HHVM 3.18.6 while the longer one is served from PHP 7.2.16.
Jul 29 2019
We can probably reduce the size for now by using the video.js core distribution (without the http-streaming component which we don't use yet) and using more aggressive minification (rather than using our own minifier, which doesn't shorted variable names and such).
Jul 26 2019
Jul 13 2019
Confirmed this fixes the transcodes; resolving.
Fixing the .ogv file by setting the 'ROTATE=180' to 'ROTATE=0':
I suspect that the 'rotate' annotation in the comments is not actually handled by Firefox, VLC, or ogv.js -- certainly I never wrote code in ogv.js to handle it -- and may be a leftover from the MP4/3gpp original file the .ogv was sourced from.
This may be a problem that's been since fixed in upstream ffmpeg...?
For me, the original plays upside-down in Chrome, right-side-up in Firefox, VLC, and ogv.js. So this ain't handled quite universally I suppose. ;) I'll take a peek.
Jul 12 2019
Jul 1 2019
Jun 29 2019
Jun 28 2019
Jun 27 2019
Note a deployment typo caused this fix to not get deployed in fact. Whoops! Roan's fixing it now.
Fix deployed. Should no longer cause fatal errors, but should log the transcoder output into the transcode table so we can review it later for suspicious commonalities.
Ok Reedy started this a while ago under T226713, so no need to re-run it a second time. It's probably the cause of seeing multiple fatals over on T226748, since all failure cases would come in a relatively short time. :D
Ah great, that'll do the job.
I have this ready to run on mwmaint1002 but want to wait until the fix for the fatal error in T226748 is deployed so I don't spam the error logs.
cleanupTranscodes.php should be able to do this I believe, I'll test offline later.
Jun 26 2019
(main difference from previous behavior is that in practice most videos got the image with popup link where now they get a video directly)
Ehhh, it's not hard to add a fallback image link that points to the file page. But I wouldn't necessarily block on it if it's not done soon.
Jun 24 2019
Note that with the "New video player" beta feature enabled, this can be tested in production -- just make sure you're logged in in the mobile browser and it will pick up the preference.
Probably should adjust the preload setting; ISTR some related issue in past. Will test further once no longer encountering unrelated server errors.
Jun 23 2019
Yeah, looks like we only read 1024 header bytes and it appears later in both those files, around 4000+ bytes in.
Confirmed that it's resolved with the video,js player frontend ("New video player" in beta features preferences)
Jun 22 2019
I was able to reproduce this locally using the files via InstantCommons, and it looks like the root problem is that some of the files are misidentifed as audio, causing the packed-gallery code to use a small icon width instead of a large width constraint here:
Note the root problem appears to be that some of the files are incorrectly marked as audio, causing a small width to be used for making thumbnails instead of a large one:
@Eatcha can you file a task for the unexpectedly small videos in gallery, and we'll track it down on that task. Thanks!
They seem to be small whether the old or new players are in use. Not quite sure why yet, will look into in a bit -- those are full size videos and should not be showing tiny... The polar bear video is low resolution, and seems to show at its native size. We may need to adjust things to ensure that video players can be sized larger than their originals?
Jun 20 2019
Closing as this was worked around where needed.
Jun 18 2019
Note that playbackRate support was recently contributed to ogv.js, so can be used when I finish packaging the new release. Shouldn't be hard to enable the rate control in the new video.js player...
@Eatcha T174393 covers this; we can add it fairly easily soon (the necessary support for the Safari compatibility shim was recently added upstream; I just have to package a release and then enable the rate control)
Jun 12 2019
Need to add a VTT parser; currently there's only a SRT parser that produces VTT-compatible objects which we can output in either format. Shouldn't be hard to add, just didn't get to it yet for the MVP. :D
Basic patch added which is an updating of the old upstream PR. Seems to work but might have edge cases; I'm happy to merge it for now to get us rolling if it looks ok.
@TheDJ yes, it's now validated (and in many cases slightly manipulated to become conforming) before being served out. As long as the formatting uses <b>...</b> and <i>...</i> rather than wiki-style '''...''' or ''...'' it will work with the upcoming videojs player -- but the old Kaltura player we're still shipping doesn't understand those.
Jun 10 2019
Upstream issue is: https://github.com/videojs/video.js/issues/5252
Jun 6 2019
Jun 4 2019
Looks like the patch never got reviewed. I'll poke some people and see if we can get it moving.
May 29 2019
May 28 2019
Ah I see! Typo, should be $title where it's $page in this:
Ah yeah that'll do it. I'll get on it...
May 26 2019
I'll investigate this Monday, probably a regression in our recent changes.
May 9 2019
May 7 2019
Once per instance is probably ok, as it should be rare to have the same video over and over. Uh, except on the file page with versions maybe. >_<
That ain't pretty. I'll see if can improve this.
IIRC production Commons is fetched into Beta via ForeignAPIRepo, so it's seeing only the srt-format subtitles in its list that production Commons sees. It should fix up after production Commons gets the timedtext API...
May 2 2019
Extension code that's dependent on specific interfaces should probably feature-detect for those specific interfaces with function_exists, class_exists etc rather than trusting version numbers as well -- and that can only be tested by running with the actual version. And you'd only detect failures (like using a new feature on the old version path) from running with the other version anyway, so I think they'd have to go together if that's something we want tested.
May 1 2019
Apr 23 2019
Apr 3 2019
Feb 28 2019
Feb 27 2019
Feb 21 2019
(Just noting I'll be ready to work more on this in around next week-ish)