[Bug] The media could not be loaded #4027
Comments
|
Is this a public instance or a private one? |
my selfhost invidous |
|
I've been having the same problem with my private instance lately as well. It seems to happen more often with newer videos, but I haven't done any testing to confirm. |
|
Can you look at the Network tab from the devtools and check the requests, see if there are any errors. If so please report them I did test with the video ID given and that was working fine for me: https://invidious.projectsegfau.lt/watch?v=Srjk6_j8J04 |
|
Specifically for me it returns And does so in rapid fashion (3 per second at least) on the frontend. Maybe it's making too many requests?
|
Which instance (public or private)? Which video ID? |
Private, videoId: nxKNibbjrbQ Tried HD720 and DASH quality. HD720 generally works OK. But DASH does the rapid fire and 403. Now getting 206s in rapid fire. Noting that this happens on newer videos only as many older videos work fine. But occasionally older videos might stop working for me but work fine after waiting some time. I think it might be related to trying to watch newer videos and then some rate limiting is happening (due to the rapid fire of the requests) or something. |
|
Having similar issues on multiple instances, but only on very new videos: I know there was an old issue with youtube being slow with their back end processing 720p that caused a similar issue last year, but this is happening on dash and 720p this time. Seem to be getting 403 errors on videoplayback: EDIT: |
|
I'm encountering the same problem on my private instance. I have attempted nearly every solution, including rebuilding the instance from scratch. For now, my temporary workaround is viewing the video on a different public instance. |
|
EDIT: NVM, I just tried disabling Pi-hole and the problem went away. Time to look at my DNS logs. |
|
Running private instance here, lately running into this issue more frequently aswell. Edit; sometimes running into this issue in a video a already half watched before. |
|
I'm having this same issue on multiple public instances, including the links provided in this thread.
|
|
Question for everyone in the thread, have you enabled video proxying? I'm wondering if YouTube might not like the IP of the server requesting the watch page being different to the computer that is actually requesting the video and audio data. |
For me i can confirm, proxying enabled |
|
Tried enabled and disabled didn’t seem to make a difference at the time, yet to have the issue today |
|
Allso, D
When I use proxying, I notice the issue on all videos. But when I turn it off, only a few videos have that problem. I've been scratching my head trying to figure out what links those specific videos. The issue seems to pop up with the 'googlevideo.com' link. I even tried turning off my VPN, disabling my custom DNS, and switching both devices and networks. But no luck – none of these tweaks made any difference.
|
|
you beat me to making this issue...guess i'll copy-paste what I would have submitted in case it is helpful. Describe the bug Every now and then, a video fails to load with a "The media could not be loaded[...]" error. After some time the error disappears. Steps to Reproduce
Additional context Something interesting is that, when this bug happens, it attempts to play from the instance, like using a proxy... but the option to use a proxy is disabled. Comparing the request of a video with this problem, and videos without this problem, I found the following:
|
|
Private, self hosted instance. |
|
Related: NewPipe had the same issue, but they fixed it by implementing a workaround in v0.25.2. (As far as I understand, correct me if I'm wrong) This is a new integrity check YouTube is currently rolling out through A/B testing. The 403 error means Invidious is failing the integrity check and thus YouTube is denying it access to the video. The reason that it only happens on some videos, and that the rate seems to be increasing, is that YouTube is rolling it out as an A/B test, meaning they start with a small % of videos, then increase as time goes on until in the end all videos have this protection and Invidious won't be able to play anything at all. The workaround that works the best for me is just waiting. Go watch a different video, come back in 5-10 mins, it should work. If it doesn't, repeat until it does. (You are basically rolling the dice whether you will get this protection or not every time you load the video) |
|
Thanks @andre4ik3. We were made aware of this special parameter a month ago but did not yet implement: https://github.com/TeamNewPipe/NewPipeExtractor/pull/1084/files#diff-e07bd9a3dfb657e0ac68c2847533825c0c25d9cc8486c9a5a0dab1d413d54d42R986 We will implement it. |
Thank you for your efforts |
Agreed, many thanks for this project |
|
Here's a quick patch that implements NewPipe's workaround. Can anyone see if this fixes the problem? Please clear or wait until the video cache expires when doing so. PatchFrom 2f6b2688bb8042c29942e46767dc78836f21fb57 Mon Sep 17 00:00:00 2001
From: syeopite <syeopite@syeopite.dev>
Date: Sun, 6 Aug 2023 12:20:05 -0700
Subject: [PATCH] Use workaround for fetching streaming URLs
YouTube appears to be A/B testing some new integrity checks. Adding the
parameter "CgIQBg" to InnerTube player requests appears to workaround
the problem
See https://github.com/TeamNewPipe/NewPipeExtractor/pull/1084
---
src/invidious/videos/parser.cr | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/invidious/videos/parser.cr b/src/invidious/videos/parser.cr
index 9cc0ffdc..2a09d187 100644
--- a/src/invidious/videos/parser.cr
+++ b/src/invidious/videos/parser.cr
@@ -55,8 +55,9 @@ def extract_video_info(video_id : String, proxy_region : String? = nil)
client_config = YoutubeAPI::ClientConfig.new(proxy_region: proxy_region)
# Fetch data from the player endpoint
- # 8AEB param is used to fetch YouTube stories
- player_response = YoutubeAPI.player(video_id: video_id, params: "8AEB", client_config: client_config)
+ # CgIQBg is a workaround for streaming URLs that returns a 403.
+ # See https://github.com/iv-org/invidious/issues/4027#issuecomment-1666944520
+ player_response = YoutubeAPI.player(video_id: video_id, params: "CgIQBg", client_config: client_config)
playability_status = player_response.dig?("playabilityStatus", "status").try &.as_s
@@ -135,8 +136,9 @@ end
def try_fetch_streaming_data(id : String, client_config : YoutubeAPI::ClientConfig) : Hash(String, JSON::Any)?
LOGGER.debug("try_fetch_streaming_data: [#{id}] Using #{client_config.client_type} client.")
- # 8AEB param is used to fetch YouTube stories
- response = YoutubeAPI.player(video_id: id, params: "8AEB", client_config: client_config)
+ # CgIQBg is a workaround for streaming URLs that returns a 403.
+ # See https://github.com/iv-org/invidious/issues/4027#issuecomment-1666944520
+ response = YoutubeAPI.player(video_id: id, params: "CgIQBg", client_config: client_config)
playability_status = response["playabilityStatus"]["status"]
LOGGER.debug("try_fetch_streaming_data: [#{id}] Got playabilityStatus == #{playability_status}.")
--
2.41.0
|
|
Looks like the patch is working. After setting up a Linux VM and figuring out how to install all the dependencies, I did a before and after of the patch. Before the patch, clicking on random videos in trending, I'd say there is like a 30% chance of getting the error. After applying the patch and clicking more videos (lower down in the trending page, not the same ones because clicking the same ones will still result in error until video cache clears), I haven't had a single media error. Nice job! |
|
I have patched the source and built the docker container locally and switched my docker stack over and have not had the problem anymore. I was having it happen non stop all day, have clicked and played about 60 videos now with no problem. |
|
Fantastic work all. Definitely been hit hard in the past week with most videos 403'ing. I was worried the "crackdown" was going to be the start of the end of the Invidious glory days, but replies above rest for now. |
Deployed it to my instance; no issues whatsoever. |
|
Hi I changed parser.cr according to the provided patch, then i ran make from the invidious directory. Did i do something wrong? Edit: The video now seems to be loading. |
|
You will have to rebuild it (I'm using https://github.com/tmiland/Invidious-Updater)
…------- Original Message -------
On Monday, August 7th, 2023 at 2:46 AM, anoo2niem - notifications at github.com ***@***.***> wrote:
Hi
I changed parser.cr according to the provided patch, then i ran make from the invidious directory.
i've restarted the invidious service, but on the video /watch?v=IHs-QqUik4E i still get the issue?
Did i do something wrong?
—
Reply to this email directly, [view it on GitHub](#4027 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AVJNT2TXIINVVQ2MEYJGYGTXUAUHHANCNFSM6AAAAAA3EBDHFQ).
You are receiving this because you commented.Message ID: ***@***.***>
|
|
Sorry if i sound stupid but didn't i just rebuild it with make? |
Rewriting cause apparently GitHub missed up the formatting to be honest I'm really not sure since I always use the invidious updater, but yeah it seems like the make command is what rebuilds it
I would try clearing the browser cache |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Adding to the conversation, I've seen the same issue using the API (iBicha/playlet#125) What's interesting here is that the video plays for a few seconds before hitting the 403 Another detail that does indicate it is an integrity check: inspecting the stream url that hit a 403 in devtools, when opening these links in their own browser tab, they work. |
Thanks for testing everyone! I've went ahead and opened up #4037 which implements the patch |
This comment was marked as off-topic.
This comment was marked as off-topic.
Describe the bug
most videos can play, but only a few videos can't play
Steps to Reproduce
xxx.com/watch?v=Srjk6_j8J04
Logs
The media could not be loaded, either because the server or network failed or because the format is not supported.
Screenshots
Additional context
The text was updated successfully, but these errors were encountered: