Files is the storage application for Phabricator. Users can upload files directly and the application is also used by other applications for file storage.
Mon, Jan 13
Sep 8 2019
Jul 31 2019
Jul 30 2019
Jun 24 2019
Jun 22 2019
See one followup in T13326. The "import from disk" part seems to have worked properly in production.
Jun 17 2019
Jun 5 2019
May 24 2019
Feb 25 2019
Feb 23 2019
We no longer offer support for this kind of problem (that technically has reproduction steps, but is sufficiently involved to reproduce that no one has time to follow them, e.g. build a new server from scratch with assorted specific software versions).
Jul 23 2018
Thanks! I was able to follow your steps to reproduce this and verify the fix.
Jul 22 2018
Note that the lints and unit tests do pass on my end. I used the "Create Diff" action to do this instead of arc diff (which was silly of me)
Jun 28 2018
Can't wait for "connect 2" to come out on playstation six.
Jun 1 2018
May 4 2018
I like that reasoning a lot better than mine, and simply omitting type appears to produce the correct behavior in every browser, at least for this file. I'll try that instead, and we can revisit this after we write a video transcoder in PHP and can offer files in multiple formats.
My knowledge is centred around broadcast video / IPTV (UDP multicast) rather than HTML5 video, but that seems fairly reasonable. I don't think anything should try and download the file twice unless it is a complete clownshoes implementation that probably has multiple other serious bugs wasting bandwidth. I think the worst case with no type that might be hit here is that the browser could decide to download the entire file on load to figure out the format and duration, rather than starting with byte-range requests, but this is easy to test and unlikely (I'd expect any sane one to always request chunks).
I can imagine that two <source /> tags might, in some bizarre world, cause browsers to download the file twice when you click "Play", if they're super confused about how to process videos, don't notice that the URLs are the same, and don't hit any caching. But that's a pretty minor bad effect, and I didn't immediately see any kind of bad behavior locally.
Thanks! I wouldn't mind parsing that but I'm hesitant to ask installs to install it -- but it's helpful in understanding that I'm not completely crazy here and that there's at least some basis for "video/mp4" being a quasi-legitimate way to label the video file.
mediainfo is the tool for this, but is really overkill for programmatic use.
May 3 2018
One easy approach we could take is just:
May 1 2018
Apr 28 2018
From PHI604, for completeness, on the newer behavior of "Hide Blame":
Apr 27 2018
validation for the configuration option
Apr 25 2018
Apr 17 2018
Apr 16 2018
See T13125 for a more detailed breakout of coverage plans.
Apr 15 2018
This particular page here is fataling: