Videos disappeared from site but still appearing on temporary site

hi there,

very strange. We are not sure what is happening with regards to video - all our investigations on netlify’s side are proving to be dead end after dead end.

it seems possible though that switching to a different video format might help:

can you try this and see if it works?

Hi Perry,

Thanks for your response. All of my videos are in mp4 format so I don’t think that I’m having the same issue as this person. Has this been an issue for many sites?

1 Like

Hey @rmerzbac

I don’t see a video on the page using either URL in Chrome or Firefox

Here is console log from Firefox

It does however work in Safari.

Your code…

<video id="vid">
  <source
    src="/static/media/rangeRegistersColors.c8310851.mp4#t=53"
    type="video/mp4">
  <source
    src="/static/media/rangeRegistersColors.c8310851.ogg#t=53,106"
    type="video/ogg">
  Video failed to load.
</video>

Part of the issue is the .ogg version does not exist hence the “Content-Type” warning in the above screenshot.

I will add that after visiting the site again (in Chrome and Firefox), the content did load. :confused:

Okay, now the video isn’t working on either URL for me either. I removed the ogg line, since I don’t think that format was being imported correctly. If I look up the videos directly (https://adoring-yonath-076396.netlify.app/static/media/rangeRegistersColors.c8310851.mp4#t=0) it seems to load. This might not be a Netlify issue.

Some more strange behavior: my preview site (https://6223d1444fb3d765171bdb96--adoring-yonath-076396.netlify.app/piccoloRRC) works fine, but the deployed site (Instrument Studies for Eyes and Ears) is still broken.

When using Firefox to browse https://isfee.music.indiana.edu/piccoloRRC I see

Media resource Instrument Studies for Eyes and Ears could not be decoded.

With further explanation:

Media resource Instrument Studies for Eyes and Ears could not be decoded, error: Error Code: NS_ERROR_DOM_MEDIA_METADATA_ERR (0x806e0006)
Details: static MP4Metadata::ResultAndByteBuffer mozilla::MP4Metadata::Metadata(mozilla::ByteStream *): Cannot parse metadata

Out of curiosity I converted the MP4 video to WebM and uploaded both with a very simple test site cocky-colden-cb9c59.netlify.app. This loaded in both Firefox and Chrome without issue and still loaded in Safari.

Edit
In cause there is something happening on Netlify’s end @perry, here is a page load (via France) with the video not loading (in Chrome.)

x-nf-request-id: 01FXDZZPPEG6MJYSRF7WHXX6PM

And here is one (via Australia) with the video loading (in Chrome.)

x-nf-request-id: 01FXE0561YJMJBTQZZHRPAK5DP

Edit 2:

Following my question here I’m adding the following

Page Request:
x-nf-request-id: 01FXHD28PSDBWV85F4K23CWWPA

Request for video
Initial (status 206):

x-nf-request-id: 01FXHD28ZBPXJ13CEDYYH856S7
Content-Length: 4207530
Content-Range: bytes 0-4207529/4207530

then (also status 206):

x-nf-request-id: 01FXHD29C35WGW8P36FHB2FQA5
content-length: 78762
content-range: bytes 4128768-4207529/4207530

I am unable to replicated a successful request now though.

This started happening to my test site with an mp4 file around 24 hours ago. After having worked without failure for 3+ months without any code changes.

I have tried uploading a new version of the video file in case of git corruption, tried different versions of html, read up on changed <video> spec, etc. to no avail.

  • The file is .mp4
  • 2.3 mb
  • Network status 206.
  • Fails with “canceled” after attempting to load 1 or 2 chunks (at random)
  • Has autoplay=“true”, but has muted=“true”, too.
  • Opening the file with its direct link on netlify.app works.
  • The same file/code combination works as expected on a website hosted at another provider.
  • Same result across different IPs and geolocations.
  • Same result with Brave on Mac and PC, Chrome and Firefox on Mac.
  • I have a report that force refreshing the page makes the mp4 request time out in a 400 status, but I have not seen this myself. I get only 206 and then “canceled” after a short delay.

I have tried with/without most of these parameters. Makes no difference:

<video preload="auto" autoplay="true" playsinline="true" loop="true" muted="true">
    <source src="/assets/video/masthead-bg.mp4" type="video/mp4">
</video>

Server timing status is “stalled”:

Response headers of the stalled chunk:

Request:

:authority: xxxxxxxxx.netlify.app
:method: GET
:path: /assets/video/masthead-bg.mp4
:scheme: https
accept: */*
accept-encoding: identity;q=1, *;q=0
accept-language: en-US,en;q=0.9
cache-control: no-cache
dnt: 1
pragma: no-cache
range: bytes=0-
referer: https://xxxxxxxxx.app/
sec-fetch-dest: video
sec-fetch-mode: no-cors
sec-fetch-site: same-origin
sec-gpc: 1
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36

Hope this gives you an idea. I can’t link to the site because of confidentiality with my client. Thanks for looking into it.

Hi, @elhansson. What would really help us to research this is the x-nf-request-id response header shown in your screenshot. We have a support guide about this here.

As that support guide states, please do not send us the x-nf-request-id header as an image. We need it as text. Would you please send us that value as text?

1 Like

Thank you @luke , here it is as text:

x-nf-request-id: 01FXHZMDET4S2MKSYTWBWA5H5S

Can confirm I’m having the same issue as @elhansson on multiple sites. For client security reasons I can’t post the urls here, but I’ve rasied an issue with Netlify support via email. We’re on the Business plan, but hoping to get a quicker update here though.

1 Like

Just to add - these are sites that have been running perfectly for several months, and no code changes have been made to them since. Suddenly the background videos are not loading today though. Loads fine when I build/serve the sites locally, only fails to load the background videos when deployed to Netlify.

3 Likes

I can confirm this exact same behavior for background videos on some of my sites. One site has a working video on one page and a broken one on the other. I can provide more info tomorrow

Hi

I had simple 7Mb embed video displayed just fine until this week.

Do I need to enable large-media features or is there anything else I am missing?

https://kind-kirch-e83511.netlify.app/

it says: Media resource https://kind-kirch-e83511.netlify.app/videos/band-horses-video.mp4 could not be decoded.

  1. But I can right click and open it in a new tab and the video file plays just fine.

  2. mp4 files without audio track , hosting just fine.

  3. Sometimes it can play, but after a refresh it won’t.

<video class="embed-responsive-item" autoplay="" muted="" loop="" controls="">
<source src="/videos/band-horses-video.mp4" type="video/mp4"></video>

I’ve moved your post to a related thread @kaanna.

Unfortunately your temporary site does not show videos either.

https://6223e2ead02cc2000867b92d--adoring-yonath-076396.netlify.app/fluteRRT

Hi, @elhansson (and everyone else in this topic). Thanks for sending the x-nf-request-id as it helped me find the issue.

This is a bug and I’ve gotten an issue filed for it.

To summarize, your sites are using an HTTP header called “range” to request only parts of the file and our CDN has started (sometimes - not all the time) sending incorrect data for this header. @elhansson, here is an real test of the file for the x-nf-request-id: 01FXHZMDET4S2MKSYTWBWA5H5S.

I’m sure you know the real URL so please feel free to replace <REDACTED URL> with the real URL to reproduce the issue locally.

First, I checked to see what the checksum was for the last 347620 bytes of data (because the file is 2347620 bytes and I used 2000000- for the range):

$ curl --compressed -s -H "range: bytes=2000000-"  <REDACTED URL> | md5sum
ca46a203923a70f229ab76c704743d33  -

Then I checked to see the checksums for the first and last 347620 bytes by requesting the full file and using head and tail to filter for just the start and end of the file. MD5 checksum are used for both of those as well.

$ curl --compressed -s <REDACTED URL> | head -c 347620 | md5sum
ca46a203923a70f229ab76c704743d33  -
$ curl --compressed -s <REDACTED URL> | tail -c 347620 | md5sum
bda33ecb2c07e86b1445e77609295e59  -

As you can see, this proves the range request asking for the end of the file (the tail) actually got the data for the start of the file (the head). The wrong 347620 bytes is sent hence the errors for the site code expecting the correct data.

Please note, I cannot always reproduce this 100% of the time. For example, I cannot trigger this now for your file, @kaanna. I correctly get the end of the file when I test. I’m almost certain that your site is being affected by the same issue. I just cannot reliably reproduce it for that URL.

Also, this seems to primarily impact files over 1 MB in size. I cannot trigger the behavior with smaller files only with those about 2 MB or larger.

We will update this topic as soon as we have more information (or to say the issue is fixed).

I appreciate everyone letting us know about this and the specific examples (like your x-nf-request-id, @elhansson) were very helpful . Thank you for taking the time to send these examples to us.

2 Likes

I think you are right in some conditions. If the media data contains audio, it means it has a meta container located on the end of file stream.

But it’s NOT Related with file size. It’s about audio track.

I have tried 9Mb of file without sound track. Files without audio are playing correctly.

Playing Correctly Without sound
Working fine

Does not play WITH SOUND
problem file

7mb file with audio is broken most of the time. But larger files without audio plays just fine.

x-nf-request-id: 01FXM7Z0J4JTF64V5DG0K85C3Q

https://kind-kirch-e83511.netlify.app/

Hi, @kaanna. I have been able to reproduce the issue on a file without audio. As I have a counter example, I must clarify that this below is not true:

To be clear, the issue is not related to the audio track in any way.

Also, the CDN doesn’t read the contents of the file so the CDN would behave no differently for a video with audio and one without. The CDN cannot tell which is which as analyzing the file is needed to determine that which the CDN definitely is not doing.

While I do believe you only see it only the file with audio, I’m sure that is only a coincidence. Again, I definitely do see this happen to videos both with and without audio.

It also happens to all file types - not just videos. Since it happens for all large files, it also proves that the audio track isn’t part of the root cause. Any large file using the range: header can be affected but it doesn’t always happen. For example, here is the correct data being sent for your URL when I test:

$ curl -s https://kind-kirch-e83511.netlify.app/videos/band-horses-video.mp4 | tail -c 1000 | md5sum
be48320130d0ac27ab247b5868133b6c  -

$ curl -s https://kind-kirch-e83511.netlify.app/videos/band-horses-video.mp4 | head -c 1000 | md5sum
34f08bb0c00c23824fb790b15642a52a  -

$ curl -s -H 'Range: bytes=7049447-'  https://kind-kirch-e83511.netlify.app/videos/band-horses-video.mp4 | md5sum
be48320130d0ac27ab247b5868133b6c  -

This does show the checksum matching the end of the file. So, above the CDN does send the correct data.

I do believe you are not seeing the same thing that I’m seeing though and that you can reproduce the issue. I just want to be clear that it cannot always be reproduced and that the audio is not the cause.

1 Like

Sorry I did not mean it’s about audio. I just wanted to help and support your point.

  • My large mp4 files without audio always plays well without a problem.
  • My small mp4 files with audio almost never plays.

Request headers for a couple of videos I use in production that have problems off and on (grouped by site):

01FXMFJNS18XE03V3JAA0YYCXG
01FXMFMSCT29D6M06M3TQZF5QG
01FXMFNQY7HVCDP1P5N7XKPQJG
01FXMFPY78YPS72CC93N7RDFZ1
01FXMFQPDYFNQ71DX4VFTMNM0P

Some of these videos show up as canceled in my network inspector. None of them have audio. Some 3MB background loops are playing, and other 1.5MB videos are not. They all have exactly the same codec, compression etc etc, if that’s of any use.