Please disable 2-factor authentication on this account - 2016-08-15 - thanks
- User Since
- Oct 7 2014, 2:49 PM (145 w, 4 d)
- IRC Nick
- LDAP User
- MediaWiki User
Tue, Jul 18
@mmodell it looks like https://commons.wikimedia.beta.wmflabs.org/wiki/File:Crystal-38.stl still has a broken thumbnail...
I would like to continue to have access, as I am still the person on the Multimedia team who has the most experience with our metrics infrastructure (such as it is), and we may need to access it in order to make product decisions in the near future, not to mention to create new metrics scripts for our upcoming products. Expiryless would be best for that in my opinion.
Mon, Jul 17
There's no way to tell without running a maintenance script on every webm file to check the tracks...but on the bright side, I think there are relatively few webm files on our servers, so we could probably run it relatively quickly.
Wed, Jul 12
Tue, Jul 11
Mon, Jul 10
Hello all, just wanted to hop in and offer a quick thought about how to accomplish the goal of the original reporter, possibly without touching UploadWizard.
I'll take a look at this, it seems like we're mislabelling some files and should fix it ASAP to avoid further problems.
Thanks for the report, sadly without more information it's hard for us to know how to proceed - if more issues like this crop up, we will take another look.
I'll run a query to check if there's other files like this, or if some webm files have been correctly labelled as audio.
Waiting for more information on tool used.
Since this doesn't seem to be an issue, I'm closing it - if there is further necessary work, please file a new bug.
Thu, Jul 6
Wed, Jun 28
Jun 22 2017
Resolved by https://gerrit.wikimedia.org/r/336454 as expected
@jcrespo since this change is only really necessary on the beta cluster right now, do we need to file a ticket for that specifically, or is it a separate process that we should do ourselves?
Jun 21 2017
Jun 20 2017
Yeah, I'm running a script right now to generate a bunch of ~400kb files, but I don't know how much more I can do.
As a preliminary result, I just uploaded a few (read: 10-20) files at a time, both smaller files and larger ones, and I didn't see any significant spike on cluster load during the timeframe of my uploads and first thumbnails. Also, all of the thumbnails generated on the first file page load, regardless of file size, up to about 22MB. I am fairly satisfied that we can handle any increased load due to this new filetype, but if we need additional testing via mass uploads through the API, then we can do so! I just need to find a bigger source of test files, since Thingiverse is getting incredibly tedious to use. (I have some thoughts on this)
Some thoughts from our prioritization:
Jun 13 2017
Jun 9 2017
Yeah, I think it's still worth asking whether we really care about this limitation, but if we do, then I'll pursue looking at another control scheme.
Jun 7 2017
@Gilles nope - when I change those variables to, e.g., Infinity and -Infinity, the only change is that rotating past the poles will make the camera freak out. I also tried adding in a "restrictPolarAngle" configuration, and not checking the angle in that case, but it didn't help.
Jun 6 2017
So, here are the results of my technical investigation:
Jun 5 2017
We don't think there have been any problems of this nature for some time, but feel free to reopen if it's still reproducible.
I don't think this is the Multimedia team's purview, removing tag.
Jun 2 2017
May 31 2017
May 30 2017
May 25 2017
May 23 2017
May 20 2017
May 15 2017
May 8 2017
Given that we removed the category in https://gerrit.wikimedia.org/r/315121, and we now have an open patch, I'm going to reopen this and move it to "Needs review" - to be shortly followed by a close assuming I like the patch.
May 4 2017
It's currently stalled awaiting some form of Wikibase on Commons, we decided it would be better to use that for storage rather than re-write the extension after it's released.
May 3 2017
The actual error message (based on my upload of DavidStatue.stl) is "Internal error: Server failed to store temporary file."
May 2 2017
Taking this now, as it is a requirement for mobile support.
Apr 27 2017
Could use some input as to the balance between the tiny number of people who use this field for a specific purpose that would be useful to readers on other wikis, compared to the tiny number of people who are confused by the field as it is...not sure where we stand on this. Lowering priority due to small impact on both sides.
AFAICT, whatever I was smoking then has gone out of style, and we have mw.Title.newFromImg() which should obviate this issue? Anyway, I don't think we need this.
This should be as simple as removing the class file and replacing wherever the constructor is called with a simple object with the correct properties.
I'm leaving this stalled until structured data is available to clear up the authorship questions present, even in the file you listed as an example. The current structure of the license template and attribution value above are not conducive to us solving this in a good way.
We won't be working on file annotations until we can store them in structured data, so this work is going to wait for a bit. You could work on this based on the current implementation of FileAnnotations, but I wouldn't recommend it, as the implementation will change.
I agree that we don't want to potentially hurt the credit on most files for a tiny use case - and I agree that we should try to fix this once structured data makes it easier for us to credit creators. Leaving stalled, but we definitely want to fix this as soon as is practicable.
Based on the long gap between responses on this bug, I'm going to guess that it's no longer an issue - especially since seemingly none of the examples still cause problems (at least for me).
Apr 25 2017
Should review and improve patch fairly soon.
This can probably be worked on pretty soon.
This is worthwhile, but it's something that will require a lot of looking into the necessity of various dependencies, and bits of code. Hopefully we can schedule this for sometime soon, but unclear exactly when.
This is not a media viewer ticket, reassigning to a more useful project...still something we should look at, though.
This should probably happen after we implement licenses in structured data.
Apr 20 2017
I also cannot reproduce. Given that there is not sufficient information to reproduce or investigate further, I will close this bug - if someone comes back and reopens it, please include more information about your browser and other configuration details so we can actually look into this.
I think this doesn't rise to the level of "normal", as it's a totally optional feature request that would only affect a pretty small subset of files and users...something to think about in the future, but not something we need to rush towards.