See one followup in T13326. The "import from disk" part seems to have worked properly in production.

In T4752#177071, @cspeckmim wrote:

setfacl -Rdm u:phab-phd:rw /var/local/phabricator/filestore
setfacl -Rm u:phab-phd:rw /var/local/phabricator/filestore

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).

Thanks! I was able to follow your steps to reproduce this and verify the fix.

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)

Can't wait for "connect 2" to come out on playstation six.

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.

One easy approach we could take is just:

From PHI604, for completeness, on the newer behavior of "Hide Blame":

validation for the configuration option

See T13125 for a more detailed breakout of coverage plans.

This particular page here is fataling: