No Videos

[Wee Mad Arthur]

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.

 

[Reef Box]

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.

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?

 

[evolved]

@revhtree or @Daniel@R2R - can one of you chime in on the exact cause of this issue again? I know it's been stated someplace before, but I don't recall when/where.

 

[Grant Beyleveld]

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

Chrome does not make range requests - the range header in the Chrome request is 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.

Safari, however, prefers to send a range request. The range header is initially set to 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.

The problem is that the R2R server ignores this range header in the request and returns the entire video file along with a 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.

I tested this by sending an HTTP request directly to the R2R server using Postman. I requested a video using the 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.

There are essentially two fixes, as I understand it:

1. Update Safari so that is accepts 200 OK responses or so that it makes Range: bytes=0- requests.
2. Update R2R to correctly send a bytes range and 206 Partial Content status code back to the client when a request is made with a Range header set.

I'm sure the quicker/easier fix would be correctly configuring R2R, not waiting for Apple to update Safari

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.

 

[Daniel@R2R Verified Admin]

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

Chrome does not make range requests - the range header in the Chrome request is 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.

Safari, however, prefers to send a range request. The range header is initially set to 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.

The problem is that the R2R server ignores this range header in the request and returns the entire video file along with a 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.

I tested this by sending an HTTP request directly to the R2R server using Postman. I requested a video using the 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.

There are essentially two fixes, as I understand it:

1. Update Safari so that is accepts 200 OK responses or so that it makes Range: bytes=0- requests.
2. Update R2R to correctly send a bytes range and 206 Partial Content status code back to the client when a request is made with a Range header set.

I'm sure the quicker/easier fix would be correctly configuring R2R, not waiting for Apple to update Safari

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.

Thanks for this explanation. I'll be sure to pass this info on.

 

[RobB'z Reef]

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

Chrome does not make range requests - the range header in the Chrome request is 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.

Safari, however, prefers to send a range request. The range header is initially set to 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.

The problem is that the R2R server ignores this range header in the request and returns the entire video file along with a 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.

I tested this by sending an HTTP request directly to the R2R server using Postman. I requested a video using the 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.

There are essentially two fixes, as I understand it:

1. Update Safari so that is accepts 200 OK responses or so that it makes Range: bytes=0- requests.
2. Update R2R to correctly send a bytes range and 206 Partial Content status code back to the client when a request is made with a Range header set.

I'm sure the quicker/easier fix would be correctly configuring R2R, not waiting for Apple to update Safari

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.

 

[chadfish]

Bump

 

[MnFish1]

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?

Videos that are hosted on Youtube work fine. Videos that are inserted to the site to not work on the MAC SAFARI BROWSER. They work fine with CHROME. And PS - it has still not been fixed.

 

[zalick]

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

Chrome does not make range requests - the range header in the Chrome request is 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.

Safari, however, prefers to send a range request. The range header is initially set to 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.

The problem is that the R2R server ignores this range header in the request and returns the entire video file along with a 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.

I tested this by sending an HTTP request directly to the R2R server using Postman. I requested a video using the 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.

There are essentially two fixes, as I understand it:

1. Update Safari so that is accepts 200 OK responses or so that it makes Range: bytes=0- requests.
2. Update R2R to correctly send a bytes range and 206 Partial Content status code back to the client when a request is made with a Range header set.

I'm sure the quicker/easier fix would be correctly configuring R2R, not waiting for Apple to update Safari

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.

Ive got the same issue running chrome on iOS.....

never had the issue with my android.

 

[argiBK]

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?

 

[MnFish1]

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?

They don’t work on my computer either I think it’s safari

 

[spsick]

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?

Same

 

[musaabi]

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?

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.