Looks like the disable didn't get done (whoops!) so it'll still be churning out those transcodes...
Here's a config tweak for the popup video player size issue, that might get pushed a little faster than the TimedMediaHandler fix: https://gerrit.wikimedia.org/r/#/c/115094/
-- brion
On Fri, Feb 21, 2014 at 10:37 AM, Brion Vibber bvibber@wikimedia.orgwrote:
In addition to the sudden burst of transcodes, we found that the player widget is sometimes aggressively selecting the small size when it should be defaulting to a larger size.
So we're temporarily disabling the small sizes again; https://bugzilla.wikimedia.org/61760 covers checking/tweaking the player to handle this case better.
-- brion
On Fri, Feb 21, 2014 at 6:07 AM, bawolff bawolff+wn@gmail.com wrote:
On Thu, Feb 20, 2014 at 7:07 PM, Brion Vibber bvibber@wikimedia.org wrote: [..]
Files should gradually populate at the smaller sizes as they get
referenced
and the new sizes are automatically added to the transcoding queue.
Please give a shout if there's any problems.
-- brion
Looks like this actually adds them to the queue all at once - 23,386 160p videos queued, 11,745 160p transcodes already done (!), which means about 85% of all videos are either already transcoded to 160p, or in the queue.
This might cause some delays in transcoding newly uploaded files, but given that in a single day there's already been almost 20,000 new transcodes, it looks like it won't take that long to be done with all of them. I'm really quite surprised how fast the transcoding is proceeding.
--bawolff
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l