#.mp4 files playback issue

82 messages · Page 1 of 1 (latest)

void timber
#

works for me

sullen sandal
void timber
#

no

#

both chrome & firefox work

sullen sandal
#

oh yeah it works now ig it fixed itself

#

weird glitch

void timber
#

and then not even use the domain lock or redirect feature

#

anyway, that was fun

sullen sandal
#

why not 😭 and anyway im having the same problem again

#

it literally fixed itself for a bit and then it came back, don't know what do anymore

void timber
#

Did you fix the link on / going to the wrong video path

#

Also wasn’t it 12s?

#

Might be misremembering, will check tomorrow

#

Im still confused why it’s trying to range read a like 8mb file

sullen sandal
#

it's just another vid i uploaded, this happens to every video

#

here's a random countdown vid from yt

#

still happens to it

#

on discord it works properly but not in the browser

void timber
#

Im in bed alr

sullen sandal
void timber
#

!remind 12h .

charred hazelBOT
#

zep_check I will remind you in 12 hours at May 21, 2024 at 8:45 UTC

sullen sandal
#

so looks like it might be something size related

charred hazelBOT
#

Reminder for @void timber: .
Set <t:1716237900:R>

void timber
#

ok so, this is a weird chrome "bug"?

for the countdown video:

  1. chrome does a GET request to the video, but then doesnt download it (probably to get the content-length header to see how long it is, but the header isnt returned by the server)
  2. chrome then does a second GET request with the Range: bytes=0- header, to "seek". however the server returns with a 200 (OK) instead of 206 (Partial content)
  3. chrome sees that the server doesnt support the Range header (because the server didnt respond with 206), and disables seeking – even though the entire thing is already downloaded

for the small video:

  1. same thing with first request
  2. chrome then does a second GET request again with Range: bytes=0-, BUT this time receives a 206
  3. chrome sees the server supports Range header and keeps seeking enabled, although it doesnt matter (again)
#

TLDR:
your server responds with 200 instead of 206 and thus chrome (stupidly) disables seeking

#

firefox works as expected

livid root
#

In fact it stops loading the file entirely

#

At least on chrome, not tested on other browsers

void timber
sullen sandal
#

shouldn't this work in the .htaccess file?

<IfModule mod_headers.c>
    Header set Accept-Ranges bytes
</IfModule>
void timber
#

your server still needs to correctly handle range requests

livid root
void timber
sullen sandal
#

so i'm using a shared hosting and i don't have any access to the server, i don't think this is something i can fix myself

#

i tried forcibly returning a 206 status code using .htaccess but that did not work

#

and just like i said, if i pause cloudflare on my website, it works fine

#

why would it work without cloudflare and it only does this when cloudflare is on?

#

if it was a error from my server then i would imagine it wouldn't work without cloudflare as well

#

just paused cloudflare right now, and every video loads

void timber
#

because it returns the proper 206 now

sullen sandal
#

so why does it not return the proper 206 with cloudflare on?

#

doesn't that show that cloudflare is doing something wrong?

#

since it works with cloudflare turned off

void timber
#

only thing I could imagine is caching, but IIRC it was bypassed already

sullen sandal
#

i tried using cache rules to bypass anything that ends in .mp4

#

did not work

#

also purged everything and tried every caching level, still did not fix the issue

void timber
#

it did work in the sense that cache was bypassed

livid root
#

Yo leo, I tried looking up for your answer to his problem earlier https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests

MDN Web Docs
HTTP range requests - HTTP | MDN

An HTTP Range request asks the server to send only a portion of an HTTP message back to a client. Range requests are useful for clients like media players that support random access, data tools that know they need only part of a large file, and download managers that let the user pause and resume the download.

#

To be frank, I don't understand how this works

void timber
#

(cf-cache-status header being DYNAMIC = bypassed)

sullen sandal
#

yeah but the video still didn't get played properly

#

or loaded

#

now with it off as you can see, it loads it properly

#

without adding anything additional to my .htaccess file

void timber
livid root
#

don't use php, solution fixed

sullen sandal
livid root
void timber
#

you arent allowed to proxy video anyway, soooo I doubt you'll get official help

sullen sandal
#

also changed browser cache TTL to respect existing headers

sullen sandal
void timber
sullen sandal
#

a 1MB video file isn't large

livid root
#

regardless of size of the file, if the format is equal to that of an animated file format then I believe it's considered a video

sullen sandal
#

and majority of people are using cloudflare to proxy their videos

livid root
#

they're using it wrong then, even I am using it wrong

#

I didn't know of this until now to be honest

sullen sandal
#

if they really wanted to do something about people that are proxying videos they would've done something a long time ago

livid root
void timber
#

he already did

sullen sandal
#

okay fixed this

#

had to set a page rule with bypass cache level and now it works properly

#

i tried doing this before and it didn't work because cloudflare didn't actually update the rules fast enough so i just thought that wasn't working

#

but yeah pretty annoying this was happening in the first place