They also don’t play when added as an attachment like this https://www.reef2reef.com/threads/is-my-tank-overstocked.746595/
I‘ve just tested and if it’s an attachment like this it can be viewed if downloaded. Can’t download embedded videos though.
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
They also don’t play when added as an attachment like this https://www.reef2reef.com/threads/is-my-tank-overstocked.746595/
with this being said does anyone know if I can adjust my settings to allow for the video to show outside of downloading another browser?That's exactly it, and captures the root of the problem.
The issue is a device/browser issue or settings that prevents or blocks playback. It is not the forum software.
On most windows or android devices using Chrome, there is no issue with playback. iOS, and especially safari, is where most blocking of playback occurs.
GET
request to the server for the video. It does this so that the entire video is not sent to the client at page load, but rather only the necessary portion of it until the user actually requests the rest of the video (i.e. hits play).bytes=0-
indicating that any the entire file is requested. The server returns a 200 OK
status code and sends all the data, and the video plays.bytes=0-1
, i.e. only the first byte is requested. Typically, the server would return just the bytes that are requested with a 206 Partial Content
status code.200 OK
status code. Safari was expecting a 206 Partial Content
status code in the response, so it rejects the response and the video does not play.Range: bytes=0-1
header and received the entire file back along with a 200 OK
status code, thus proving that R2R ignores the Range
header.200 OK
responses or so that it makes Range: bytes=0-
requests.206 Partial Content
status code back to the client when a request is made with a Range
header set.Thanks for this explanation. I'll be sure to pass this info on.I came looking for a reason/solution here. After some Googling, it seems the problem has been documented here and a more casual explainer is available here.
In summary, embedded videos work in Chrome but not Safari. This is because Safari requests a byte range when making theGET
request to the server for the video. It does this so that the entire video is not sent to the client at page load, but rather only the necessary portion of it until the user actually requests the rest of the video (i.e. hits play).
Chrome does not make range requests - the range header in the Chrome request isbytes=0-
indicating that any the entire file is requested. The server returns a200 OK
status code and sends all the data, and the video plays.
Safari, however, prefers to send a range request. The range header is initially set tobytes=0-1
, i.e. only the first byte is requested. Typically, the server would return just the bytes that are requested with a206 Partial Content
status code.
The problem is that the R2R server ignores this range header in the request and returns the entire video file along with a200 OK
status code. Safari was expecting a206 Partial Content
status code in the response, so it rejects the response and the video does not play.
I tested this by sending an HTTP request directly to the R2R server using Postman. I requested a video using theRange: bytes=0-1
header and received the entire file back along with a200 OK
status code, thus proving that R2R ignores theRange
header.
There are essentially two fixes, as I understand it:
I'm sure the quicker/easier fix would be correctly configuring R2R, not waiting for Apple to update Safari
- Update Safari so that is accepts
200 OK
responses or so that it makesRange: bytes=0-
requests.- Update R2R to correctly send a bytes range and
206 Partial Content
status code back to the client when a request is made with aRange
header set.
I'm not familiar with the backend of R2R, but whomever is maintaining it should know that this is not a Safari bug, per se, but more specifically an inflexibility of Safari coupled with an incorrect response from the server.
Lastly, the simplest solution for the immediate short term is to use Chrome
@revhtree @Daniel@R2R hope this helps and can be passed onto the relevant site admin.
This is gold, kudos for taking the time to sort this out.I came looking for a reason/solution here. After some Googling, it seems the problem has been documented here and a more casual explainer is available here.
In summary, embedded videos work in Chrome but not Safari. This is because Safari requests a byte range when making theGET
request to the server for the video. It does this so that the entire video is not sent to the client at page load, but rather only the necessary portion of it until the user actually requests the rest of the video (i.e. hits play).
Chrome does not make range requests - the range header in the Chrome request isbytes=0-
indicating that any the entire file is requested. The server returns a200 OK
status code and sends all the data, and the video plays.
Safari, however, prefers to send a range request. The range header is initially set tobytes=0-1
, i.e. only the first byte is requested. Typically, the server would return just the bytes that are requested with a206 Partial Content
status code.
The problem is that the R2R server ignores this range header in the request and returns the entire video file along with a200 OK
status code. Safari was expecting a206 Partial Content
status code in the response, so it rejects the response and the video does not play.
I tested this by sending an HTTP request directly to the R2R server using Postman. I requested a video using theRange: bytes=0-1
header and received the entire file back along with a200 OK
status code, thus proving that R2R ignores theRange
header.
There are essentially two fixes, as I understand it:
I'm sure the quicker/easier fix would be correctly configuring R2R, not waiting for Apple to update Safari
- Update Safari so that is accepts
200 OK
responses or so that it makesRange: bytes=0-
requests.- Update R2R to correctly send a bytes range and
206 Partial Content
status code back to the client when a request is made with aRange
header set.
I'm not familiar with the backend of R2R, but whomever is maintaining it should know that this is not a Safari bug, per se, but more specifically an inflexibility of Safari coupled with an incorrect response from the server.
Lastly, the simplest solution for the immediate short term is to use Chrome
@revhtree @Daniel@R2R hope this helps and can be passed onto the relevant site admin.
Here’s one of my videos for you to test. This content is hosted on YouTube, and is 1:29 minutes long. Let me know if it plays:
Also, are you only having the problem with videos posted here on R2R, or on other websites as well?
Ive got the same issue running chrome on iOS.....I came looking for a reason/solution here. After some Googling, it seems the problem has been documented here and a more casual explainer is available here.
In summary, embedded videos work in Chrome but not Safari. This is because Safari requests a byte range when making theGET
request to the server for the video. It does this so that the entire video is not sent to the client at page load, but rather only the necessary portion of it until the user actually requests the rest of the video (i.e. hits play).
Chrome does not make range requests - the range header in the Chrome request isbytes=0-
indicating that any the entire file is requested. The server returns a200 OK
status code and sends all the data, and the video plays.
Safari, however, prefers to send a range request. The range header is initially set tobytes=0-1
, i.e. only the first byte is requested. Typically, the server would return just the bytes that are requested with a206 Partial Content
status code.
The problem is that the R2R server ignores this range header in the request and returns the entire video file along with a200 OK
status code. Safari was expecting a206 Partial Content
status code in the response, so it rejects the response and the video does not play.
I tested this by sending an HTTP request directly to the R2R server using Postman. I requested a video using theRange: bytes=0-1
header and received the entire file back along with a200 OK
status code, thus proving that R2R ignores theRange
header.
There are essentially two fixes, as I understand it:
I'm sure the quicker/easier fix would be correctly configuring R2R, not waiting for Apple to update Safari
- Update Safari so that is accepts
200 OK
responses or so that it makesRange: bytes=0-
requests.- Update R2R to correctly send a bytes range and
206 Partial Content
status code back to the client when a request is made with aRange
header set.
I'm not familiar with the backend of R2R, but whomever is maintaining it should know that this is not a Safari bug, per se, but more specifically an inflexibility of Safari coupled with an incorrect response from the server.
Lastly, the simplest solution for the immediate short term is to use Chrome
@revhtree @Daniel@R2R hope this helps and can be passed onto the relevant site admin.
They don’t work on my computer either I think it’s safariBringing this back up to the top.
None of my browsers on iPad (Safari, Chrome, Firefox, Opera) are able to play videos uploaded directly to R2R. Is there any solution to this short of accessing on a non-iOS device?
SameBringing this back up to the top.
None of my browsers on iPad (Safari, Chrome, Firefox, Opera) are able to play videos uploaded directly to R2R. Is there any solution to this short of accessing on a non-iOS device?
Yup doesn’t work on iOS regardless of browser. If there is a fix for this on r2r end you guys should implement it. Doesn’t seem likely that Apple is worried about us using this site enough to update iOS for this.Bringing this back up to the top.
None of my browsers on iPad (Safari, Chrome, Firefox, Opera) are able to play videos uploaded directly to R2R. Is there any solution to this short of accessing on a non-iOS device?