We’re seeing an issue on 3.6.0.beta3-latest where iPhone and Safari on macOS users get an endless spinner when attempting to play an uploaded .mp4 (H.264) video. These same videos played fine until recently (I’m not sure what the last version of Discourse was when they worked).
It looks like Safari makes a GET to fetch the first bytes (Range: bytes=0-1) of the video (eg /uploads/default/original/1X/44395933ccadf546b1b1ce65b742e24f900b33fa.mp4), which returns 200 but fails for reasons that aren’t shown in the JS console or network inspector (just highlighted in red, no error messages). If the same URL is pasted into the browser directly, they are able to successfully download the full video and play it.
Firefox and Chrome on macOS have no issues playing the videos. Browsers on Android also don’t appear to be having issues.
The videos are small (in the 10MB range). We aren’t using S3 for uploads.
Can anyone else corroborate, or confirm that they’re not having issues with iPhones/Safari playing videos? And is there any other diagnostic I can do that might cast light on the issue?
I’m facing a similar issue with my forum, but testing the same files here appears to work fine. Only iOS/Safari users are affected. Some videos in the WEBM container work, but most mp4, mov, etc, do not.
Hi, I’ve been seeing issues recently and commented into a thread started by @tsk which has been de-listed. I was working under the assumption that the problem was with mp4/av1 encoded videos as webm/vp9 videos were playing on our forum, but it’s starting to look like the issue is more than that for Safari users.
This video is H.264 in MP4, it should play on all browsers that run Discourse. Given it runs here and not on your instance, I suspect there is something misconfigured there.
Do you run any extra reverse proxy on top of Discourse? I’ve seen some headers on this instance that don’t exist on standard installs, so I’m curious on what was done there.
I had considered this may be partly responsible but the config has not changed and this is a new issue to 3.6.0-beta2 from what I could tell. I started receiving complaints from apple users after rebuilding. Similar to @mandyk I dont remember what we were on previously.
Unfortunately we can’t realistically cover all infinite possibilities of configurations when people add stuff on top of Discourse, which is why we ship with a know good configuration on the standard install that comes with a reverse proxy configured for Discourse.
It may be missing a single nginx config stanza, but you will need to research into that.
Also confirming that the video posted in this thread plays fine in Safari.
Not sure if this is relevant, but one difference I can spot is that the video in this thread is being served from S3. When Safari makes the first range request, S3 is replying with HTTP 206, which seems correct. Both the Pixelspace instance and my instance are not using S3, and it seems that Discourse is replying with HTTP 200 (which doesn’t seem correct, because the request includes a Range: bytes=0-1 header).
Confirmed that the video on discourse-on-a-pi5.falco.dev is not working for me on Safari. Again, I can see that the video request is returning 200 instead of 206.
Edit: Additionally, it seems like the response is attempting to return the whole video even though Range: bytes=0-1 was specified. I suspect range requests are being ignored, and Safari seems to be sensitive to this.
Further edit: This probably means efficient seeking on larger videos is broken for browsers other than Safari too, as they need to download the entire video before being able to seek.
So just for additional giggles, I copied my app.yml to app2.yml, changed the url and a couple directories, and we now have testfor.pixelspace.xyz running stable branch.
