@Sachin I only noticed this issue occurring after I upgraded to Safari 16 last week. In previous Safari versions, I never experienced this specific issue occurring.
@Sagi_Kolodaro I tried to reproduce this issue but everything seems to work as expected. I do see the blank image that you mentioned during the initial few seconds of page load, but that too goes away.
Could it just be a slow internet connection?
Does the page load well in other browsers with/without Requestly?
@Sagi_Kolodaro There have been some recently reported issues around the rendering of avif streams. I see that the container for the media files here is gif and not avif but couldnât confirm what was the type of the video stream.
Just wanted more info to confirm that the proxy isnât messing up the received data stream.
@nsrCodes I retested once again today on Mac Safari 16.0 and the issue still occurs whenever the Requestly desktop app is enabled (with/without the Requestly rules enabled) and as a result, the player displays only as a black rectangle on the page (no matter how long I wait). As soon as I close the Requestly desktop app the clips immediately begin to play on the player. If I reopen the Requestly desktop app and refresh the same browser page then once again the black rectangle appears permanently. Whenever the black rectangle appears I verify via https://amiusing.requestly.io/ that I receive the âSuccessâ message.
@nsrCodes When the player first appears on the page is displays a .jpg file once it starts playing it streams the .m3u8 hls file in Mac Safari/iOS otherwise it streams the .mp4 file in all other desktop browsers in Windows and Android
@Sagi_Kolodaro Thank you so much for being patient.
Since I wasnât able to reproduce the exact issue myself I tried to work on the information that you provided about the player using an hls stream in this case.
Each segment of an hls stream is a an arbitrary binary stream which is returned with a content type of applicatoin/octet-stream . We have had many similar, hard to reproduce, bugs in the past related to octet streams
We are working on fixing this but in the meantime here are a few suggestions to help you get things working for now
Since the hls stream is the problem, we can trick the player into believing that we are on windows and make it use the mp4 stream instead. This can be done using the user agent rule and setting it to something like Windows tablet. After the rule is applied, the network tab shows no calls to the m3u8 stream
Here is a template rule that you can further modify for the different sites that you use (or maybe even directly point it to your cdn endpoint)
We have recently fixed a similar issue issue for google meet by adding it to the bypass list of OSXâs system proxy settings. this way the requests for meet.google.com never went through Requestly. For now you can follow these instructions to add either ford-trucks.com or cdn5.anyclip.com to your systemâs bypass list.
You can also choose to bypass proxy settings for specific computers on the internet (hosts) and segments of the internet (domains) by adding the address of the host or domain in the âBypass proxy settings for these Hosts & Domainsâ field
I was able to reproduce a similar error on hls-demo player. In my case the site was not loading at all. Setting up the bypass list helped me solve it for now
Note: We are also working on providing an easy way to update this system bypasslist from within the Requestly app. If this works well for you, we would love to get your feedback on how you think we should implement it to make it easy to use.
