Tue, Jul 10
Fri, Jun 29
Seems to have cleared up for me too now. Marking resolved. \o/
and in ipv4:
$ sudo mtr bast1002.wikimedia.org -z --report-wide Password: Start: 2018-06-29T10:07:32-0700 HOST: Orac.local Loss% Snt Last Avg Best Wrst StDev 1. AS7922 2601:1c0:5201:b82:2cab:a4ff:fe47:1245 0.0% 10 5.9 5.9 3.5 13.5 2.9 2. AS7922 2001:558:4060:26::1 0.0% 10 13.8 21.0 13.4 55.8 12.5 3. AS7922 ae-225-rur02.beaverton.or.bverton.comcast.net 0.0% 10 17.0 16.1 12.9 27.2 4.2 4. AS7922 ae-51-ar01.troutdale.or.bverton.comcast.net 0.0% 10 17.6 17.4 14.0 19.5 2.0 5. AS7922 be-33490-cr01.seattle.wa.ibone.comcast.net 10.0% 10 21.4 23.9 20.1 29.1 3.4 6. AS7922 be-10846-pe01.seattle.wa.ibone.comcast.net 0.0% 10 27.0 22.8 18.1 28.7 3.5 7. AS7922 2001:559::536 0.0% 10 17.1 22.9 16.8 45.4 9.2 8. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
Wed, Jun 27
Ah, I figured it out. It was only triggering when editing was started from the article view (in which case TMH was already loaded), whereas in most of my testing I was reloading at the action=edit page, with no TMH loaded. I can now reliably trigger it. :D
Tue, Jun 26
I'm having trouble reproducing this in an isolated environment.
Yeah, looks like the old-style mwembed player in TMH is getting confused about the parsoid-style markup and is ending up with a zero-size widget. Do y'all prefer that I try to fix the frontend to work with that markup, or leave it to to changing which markup is used (T154844)?
Gotcha -- yes, can reproduce the bug in Chrome and Safari. Thanks for filing the side bug. :)
(I do see that the thumbnail changes on the example taken from the referenced article; it looks like the 'thumbtime' parameter is not being passed through when the thumbnail is reloaded, so it gets the default time.)
In Chrome I'm not experiencing disappearing thumbnails or unusual size on https://en.wikipedia.org/wiki/User:Brion_Vibber_(WMF)/Video_VE_test when testing either of:
- changing size of video through 'edit' / advanced
- changing size of video by dragging the corner
- inserting a new video
*chef's kiss emoji* that's a perfect fix, and much simpler than extracting the info and adjusting size manually. Many thanks Gilles!
Mon, Jun 25
Can get the base size and the display aspect ratio from ffprobe by extending the call to something like this:
Sun, Jun 24
Fri, Jun 22
Thanks! Unfortunately it looks like 3.2 doesn't include support for the option. We'll either need to update to 3.3 or 3.4 or add in a backport of https://github.com/FFmpeg/FFmpeg/commit/734d760e2fb2621040edef3536b5935e7bc45351 which might be easier.
Turned out the delayed initialization workaround was only being done on iOS. Simply removing the check means we do the same logic on macOS, and it now works whether on the old or new Safari. Yay!
Thu, Jun 21
Wed, Jun 20
Just want to withdraw my old objections form very early discussion on this task; based on seeing the social dynamics of the projects over the years, this is indeed something likely to be useful in practice for enforcing per-topic bans etc.
@Physikerwelt I'd start a note in the readme file. Some things to consider:
Jun 18 2018
Awesome thanks! I _think_ it should be straightforward. :)
To test if ffmpeg version is built & linked against the correct library:
Note that this should eliminate or reduce the encoding-time penalty on VP9 by letting us use more threads per conversion. This is particularly important for very long videos at high resolution (conference talks and such), where otherwise we might run past the time limits on the total encoding.
Jun 12 2018
Jun 7 2018
Yay! That was pretty straightforward. Math apparently now defaults to using WMF's public rest service for math rendering, which might not be the best default (?) but that's a topic for another bug and another day! :)
Jun 6 2018
sh: 1: prebuild-install: not found is suspicious
Seems to have caused Math installation to fail on MediaWiki-Vagrant, which still tries to compile texvc: T196590
Well this is suspicious in Math:
Jun 1 2018
May 31 2018
@Jdlrobson I just uploaded my current version of it. I've got the parser function & page prop working, but trying to shove it into the extended file metadata may be a mistake. Currently it fails in concert with CommonsMetadata extension. I'll see if there's a saner way to do this tomorrow. :D Feel free to take a peek! https://gerrit.wikimedia.org/r/436434
May 25 2018
Unblocked, got a patch for that. :D Will poke further along today.
Blocked by T195580
Probably same as T195580?
Got sidetracked on a research project; continuing. :)
May 24 2018
May 21 2018
May 3 2018
For TimedMediaHandler that'd be me -- I'll do a spike on this tomorrow. :)
I've set the admins to Mark and Cindy and sent them an updated admin pass; feel free to adjust further amongst yourselves. :)
(whoops already filed as https://phabricator.wikimedia.org/T191123 )
Ok, this should be fixed and working with latest versions of everything as of latest commit.
Ok, I can confirm that under Ubuntu, with NFS on, I get the same error. About to test the to_s suggestion to see if that helps...
May 2 2018
I'm using Vagrant 2.0.4 and VirtualBox 5.2.10 on my Win10 and MacOS High Sierra machines and haven't hit this problem yet... Will test under Ubuntu 18.04 and see if it behaves differently.
Apr 29 2018
@Deltakosh babylonjs is something to consider too! One thing is we need a headless mode to render flat thumbnails as well as the live viewer... We've managed to get three.js running under node with headless WebGL, though sometimes it's a little funky to add new features to it. Is there a headless mode available for babylon as well? (In theory we could change from node to headless Chrome or Firefox but that's a whole other thing to arrange with ops, probably. :)
Apr 27 2018
Fix went live a couple hours ago, all files uploaded since then seem to be detecting metadata ok. May need to run a script to fix up the broken ones per-wiki, I'll look into that tomorrow.
Fix is merged for new branches, will merge for older branches tomorrow after confirming the backport.
Apr 26 2018
Looks like more Debian Stretch api & app servers got into the mix in the last few days, which probably explains it.
@MoritzMuehlenhoff logs show poppler-utils was updated for security recently; if that involved updating some machines to a newer version from an old old version it might be triggering this. If so, the patch to PdfHandler above *should* resolve the issue with compatibility for both old and new poppler-utils version...
Looks like that was reported by third-party users as T117839 some while back. It might just be hitting us now due to a package change?
This may be an issue with inconsistent versions of poppler-utils/pdfinfo installed, maybe? In local testing that with poppler 0.48.0 in Debian Stretch, it looks like the -meta (metadata) and -l 999999 (give sizes for pages up to 999999) seem to be at odds.
I'm seeing 0x0 and broken thumbnails on Commons itself for a bunch of other recently uploaded PDF files, could be related issue with some machines missing something used for metadata loading?
Apr 25 2018
A parser function that sets a page prop with the target time should be fairly easy to create on the backend, with prettier UX for setting it via GUI something to consider as an alternative or future addition.
There's interest in this again due to T92457 -- PageImages sometimes selects a video that's listed prominently, and it'd be easy for everyone if the default thumbnail could be set nicely.
Ok, so looks like two possible routes here (which may work together nicely, as well):
Editors can use the thumbtime parameter to set the thumbnail to load from a particular timestamp: https://www.mediawiki.org/wiki/Extension:TimedMediaHandler#Syntax_synopsis
Is there a problem preventing using still images from videos, specifically, or is there another reason y'all are trying to blacklist videos? And is it just videos or anything with extra parameters? Does this affect PDF, TIFF, and DjVu files with multiple pages, for instance, or SVG files rendered with a particular language?
Apr 24 2018
This went out a while ago, can confirm it's running. \o/
Ah right, forgot about that mode of the script! I'll test it and adjust when my VM's back up and running later today...