iv-org/invidious

[Question] "The media could not be loaded, either because the server or network failed or because the format is not supported." - inv_sig_helper missing

DUOLabs333 opened this issue · 61 comments

Solution here: #4947 (comment)


Describe the bug
For almost all videos (shorts and a few other videos seem to be immune), I started getting this error: "The media could not be loaded, either because the server or network failed or because the format is not supported." This started about 2 days ago.

Steps to Reproduce

  1. Go to https:///watch?v=tPTvG0Se7L8
  2. See error

Logs

Screenshots

Additional context

  • Browser (if applicable): Chrome 120
  • OS (if applicable): macOS 11

I tried adding the po_token and visitor_data from https://github.com/iv-org/youtube-trusted-session-generator, but it didn't help.

Switching to master-arm64 also didn't help.

This seems to be a duplicate of #4889.

I don't know, I'm experiencing a similar issue and the workaround described in #4889 doesn't seem to work for me.

Here's an example: https://mysupercoolinvidious/watch?v=a4RKGuTL7NE

It seems a bit sporadic - eventually I manage to make it through and watch the video, but it can take several attempts or even waiting for a few hours. I've managed to repro this in several combinations of devices and browsers:

  • MacOS 14.6.1: both Firefox and Safari
  • Linux 6.4: Firefox
  • iOS 18.0: both Safari and Yattee

It's also happened for me using both latest-arm64 and master-arm64.

These lines in the browser console seem interesting:

WARN: Specified “type” attribute of “application/dash+xml” is not supported. Load of media resource /api/manifest/dash/id/a4RKGuTL7NE?local=true&unique_res=1 failed. Trying to load from next <source> element.
ERROR: VIDEOJS: ERROR: (CODE:4 MEDIA_ERR_SRC_NOT_SUPPORTED) The media could not be loaded, either because the server or network failed or because the format is not supported. 
Object { code: 4, message: "The media could not be loaded, either because the server or network failed or because the format is not supported." }
[video.js:163:49](https://mysupercoolinvidious/videojs/video.js/video.js?v=a021b93)
    LogByTypeFactory https://mysupercoolinvidious/videojs/video.js/video.js?v=a021b93:163
    error https://mysupercoolinvidious/videojs/video.js/video.js?v=a021b93:351
    error https://mysupercoolinvidious/videojs/video.js/video.js?v=a021b93:28175
    handleTechError_ https://mysupercoolinvidious/videojs/video.js/video.js?v=a021b93:26287
    loadTech_ https://mysupercoolinvidious/videojs/video.js/video.js?v=a021b93:25292
    dispatcher https://mysupercoolinvidious/videojs/video.js/video.js?v=a021b93:2250

If this is really a config issue, I'd love to learn how to fix it!

@thebozzcl Interesting --- I don't have any error in my logs, I'll check the console.

Some videos play, some don't. If video doesn't play Invidious logs line like this:

[info] 403 GET /videoplayback?expire=1727226407&ei=xw3zZrH4BoKP6dsPzNiXgQI&ip=%exitip%&id=o-AK-S98aTvLIXROYgmqOHSXcf1A_wjXpqznWX_FcmFE-F&itag=18&source=youtube&requiressl=yes&xpc=EgVo2aDSNQ%3D%3D&mh=Ou&mm=31%2C29&mn=sn-5hne6ns6%2Csn-5hnekn7s&ms=au%2Crdu&mv=m&mvi=2&pl=24&initcwndbps=403750&bui=AXLXGFRxdtpmMpZit8qpksdmwFjHIUY27eihhqA0U3tODpkaliI6vrmRE3rWJBAep96f8DrDyPR8G9LD&spc=54MbxYwQGsKvF50aSjefFb5JFfsHLg-Tk9HnxpW3wR3ZZoaofNBDCEI8oHbj&vprv=1&svpuc=1&mime=video%2Fmp4&ns=5xxgFfmUwq_0z_LxdBMEo5AQ&rqh=1&gir=yes&clen=11846072&ratebypass=yes&dur=304.227&lmt=1692988678086191&mt=1727204477&fvip=3&fexp=51300761&c=WEB&sefc=1&txp=1319224&n=eNRVLEVo1KBZalTeVV&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cxpc%2Cbui%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cns%2Crqh%2Cgir%2Cclen%2Cratebypass%2Clmt&sig=AJfQdSswRQIhAPBAI78F80BK5md8Ol_t5ffQGWIuq9oj7GJKbGZMoN9iAiAJL7HFz8oIMUIdTyXgSOue70qheQoSGNOGH0v4wpd3Qg%3D%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=ABPmVW0wRQIhAP1O3Z_9f8qz-4E4yeXK8zS6L0wuG0buvAZBWkASMQBqAiBvQKLQR7ROqAsqLlkkK5r8VT1EfBXhwQYtb4mtdqewbg%3D%3D&host=rr2---sn-5hne6ns6.googlevideo.com 226.0ms

It's completely random

I'm getting the same error as @kkwpsi both for normal videos and for live streams using the latest release.

#4889 looks different to me, the The media could not be loaded, either because the server or network failed or because the format is not supported error is the generic browser error for when something goes wrong. That issue doesn't post server logs, and moreover the original video they have issues playing works fine on my instance.

The comment/logs on that issue from today are the same as this one, but they seem unrelated to the original post.

This may be due to #4734 (comment)

Check the devtools to see what's the status code of each request.
If it's 403 then inv sig helper may need an update.

@unixfox I'm not sure which requests are important, but I can see at least 3 that return a 403: /latest_version, and two calls to /videoplayback.

Was having the same issue today. Stumbled across this issue but was able to fix it by amending my compose yaml. Had to add inv_sig_helper from the https://docs.invidious.io/installation/ (docker-compose method (production)) and then subsequently add visitor data and po token. @DUOLabs333 Did you also do this or did you only add the token and data?

I didn't set up the sig_helper --- I didn't even know that existed until today.

I suspect that your issue then is probably that you set up your token and data but are not running the sig helper. Add signature_server: inv_sig_helper:12999 to your yaml under Invidious and then add

inv_sig_helper:
    image: quay.io/invidious/inv-sig-helper:latest
    command: ["--tcp", "0.0.0.0:12999"]
    environment:
      - RUST_LOG=info
    restart: unless-stopped
    cap_drop:
      - ALL
    read_only: true
    security_opt:
      - no-new-privileges:true

Then recreate.

Edit: Formatting

I set up everything (at least I think so --- I can see the sig helper running), and I get the same error.

Oh, I think it does work, but cached videos (even those that were opened unsuccessfully) are not sent to the helper.

@unixfox How do you drop cached videos from the database? I used to have it in my container-compose.py, but I must have deleted it (probably because I had no need for it).

Was just about to comment with my compose.yaml. Mine seems to be opening even videos that didn't successfully open before. Did you fully bring down the containers using docker compose down and bringing it back up with docker compose up -d?

Yes --- after stop, I checked that no Invidious-related processes are running and that the container is no longer mounted.

Are you managing your containers in Portainer?

Oh, I think it does work, but cached videos (even those that were opened unsuccessfully) are not sent to the helper.

Yeah, truncation was needed (I remembered the command --- psql -d invidious -c 'TRUNCATE TABLE videos')

Are you managing your containers in Portainer?

No, I use my own scripts.

Gotcha. So it seems sig helper must be necessary now for normal function of Invidious. Since I first posted about an hour ago I haven't run into any issues so please keep us all updated if you run into any issues yourself.

Yeah, disabling the helper brings back the error.

Should this be closed now, with maybe an update to invidious' README?

Also fixed the problem for me (also for previously failed videos); also did not know that this was needed. It's in the install docs already, but I didn't know it changed/had an update.

Some sort of notification for new install requirements would be cool!

Thanks for the info/fix :)

wtf how can an old issue be a duplicate of a new issue?? AI-ification is making everything worse

The above fix doesn't appear to be working for me. I don't know how I'd check if the sig helper is actually doing anything however. I do see some sig and lsig tags in the requests to google, though no idea if that's relevant.

I have tried clearing out the cached videos, but

postgres@9ff3c0e5b3f8:/$ psql invidious -c "TRUNCATE TABLE videos"
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  role "postgres" does not exist

(no idea what to make of that either :/ )

Also fixed the problem for me (also for previously failed videos); also did not know that this was needed. It's in the install docs already, but I didn't know it changed/had an update.

Some sort of notification for new install requirements would be cool!

Thanks for the info/fix :)

Invidious has releases now! With a changelog of what changed: https://github.com/iv-org/invidious/releases/tag/v2.20240825

So there were technically an announcement back in the end of august.


So you need to add inv_sig_helper and potoken now. By following the updated documentation: https://docs.invidious.io/installation/


potoken and inv_sig_helper are not an hard requirement since some IP address may still work on the old method.

If you haven't followed there were actually a constant fight against youtube from June to September: #4734.

Invidious lost for the moment and the IP addresses of most datacenter are blocked.

After adding po_token and visitor_data, I am getting this error:

audio append of 61410b failed for segment #0 in playlist 0-placeholder-uri-AUDIO-audio-main

Edit: after restarting for a few times, it's working now! (incase you want to use my instance: https://yt.hcrypt.net)

gigq commented

Getting the same error, installing inv_sig_helper and potoken haven't made a difference. I'm running outside of docker if that matters but have all the requirements mentioned in this thread running and still get the "The media could not be loaded, either because the server or network failed or because the format is not supported."

@gigq Make sure the signature_helper key is in the yaml config, and that you truncated the videos database.

In reality i cant watch any video anymore on using this program because of "The media could not be loaded, either because the server or network failed or because the format is not supported." cant listen audio/ download too . This error started last week here. I see youtube_dl cant be used too this time to get videos.

gigq commented

@gigq Make sure the signature_helper key is in the tank config, and that you truncated the videos database.

Thank you that worked. For anyone else running outside docker these are the additional steps:

Pull the latest invidious, recompile.

Generate po_token and visitor_data identities (https://docs.invidious.io/installation/#generate-po_token-and-visitor_data-identities)

Add the po_token and visitor_data to your config.yml

Build and run inv_sig_helper (https://docs.invidious.io/installation/#run-inv_sig_helper-in-background)

Add signature_server to your config.yml
If you are running it locally this should be "signature_server: 127.0.0.1:12999" however I also had to specify this at start up when running inv_sig_helper even though that port is supposed to be the default: inv_sig_helper_rust --tcp 127.0.0.1:12999

Anyways this got me back up and running hope it helps others.

If anyone wants to keep rotating the tokens, I wrote this small script which you can run in a cronjob:

output=$(docker run quay.io/invidious/youtube-trusted-session-generator)

visitor_data=$(echo "$output" | awk -F': ' '/visitor_data/ {print $2}')
po_token=$(echo "$output" | awk -F': ' '/po_token/ {print $2}')

sed -i "s/visitor_data:.*/visitor_data: $visitor_data/" docker-compose.yml
sed -i "s/po_token:.*/po_token: $po_token/" docker-compose.yml

docker compose up -d invidious

@gigq Make sure the signature_helper key is in the tank config, and that you truncated the videos database.

Thank you that worked. For anyone else running outside docker these are the additional steps:

Pull the latest invidious, recompile.

Generate po_token and visitor_data identities (https://docs.invidious.io/installation/#generate-po_token-and-visitor_data-identities)

Add the po_token and visitor_data to your config.yml

Build and run inv_sig_helper (https://docs.invidious.io/installation/#run-inv_sig_helper-in-background)

Add signature_server to your config.yml If you are running it locally this should be "signature_server: 127.0.0.1:12999" however I also had to specify this at start up when running inv_sig_helper even though that port is supposed to be the default: inv_sig_helper_rust --tcp 127.0.0.1:12999

Anyways this got me back up and running hope it helps others.

If you're running it locally (and outside of Docker), you should use a UNIX socket instead, since it'll be more performant and usable than TCP

Confirmed working after adding the signature helper! Now I need to find a setup that can rotate the trusted sessions automatically within Docker Swarm.

Hello I added the signature helper but most videos still don't work and I get 403 GET /videoplayback error. Weirdly enough I found that MKBHD videos work with a 206 GET /videoplayback status but anything else does not.

Signature helper at log startup

inv_sig_helper-1  | [2024-09-26T00:00:29Z INFO  inv_sig_helper_rust] Fetching player
inv_sig_helper-1  | [2024-09-26T00:00:30Z INFO  inv_sig_helper_rust::player] Fetching player JS URL: https://www.youtube.com/s/player/c9dd45ed/player_ias.vflset/en_US/base.js
inv_sig_helper-1  | [2024-09-26T00:00:30Z WARN  inv_sig_helper_rust::player] nsig function ending did not work: =\s*function(\([\w]+\)\{\s*var\s+[\w\s]+=[\w\.\s]+?\.call\s*\([\w\s$]+?,[\(\)\",\s]+\)[\S\s]*?\}\s*return [\w\.\s$]+?\.call\s*\([\w\s$]+?\s*,[\(\)\",\s]+\)\s*\}\s*;)
inv_sig_helper-1  | [2024-09-26T00:00:30Z INFO  inv_sig_helper_rust::player] sig code: var iCa;var iL={Z2:function(a,b){a.splice(0,b)},
inv_sig_helper-1  |     h5:function(a){a.reverse()},
inv_sig_helper-1  |     YZ:function(a,b){var c=a[0];a[0]=a[b%a.length];a[b%a.length]=c}};iCa=function(a){a=a.split("");iL.h5(a,0);iL.Z2(a,3);iL.YZ(a,4);iL.YZ(a,25);iL.h5(a,21);iL.Z2(a,2);iL.YZ(a,17);iL.YZ(a,29);return a.join("")}
inv_sig_helper-1  | [2024-09-26T00:00:30Z INFO  inv_sig_helper_rust] Successfully fetched player

@MenacingMight Did you add the signature_helper to your yaml?

Adding to the thread - went through the process of running the session generator via docker run quay.io/invidious/youtube-trusted-session-generator, got the two keys

  • po_token
  • visitor_data identities

plugged them into docker-compose.yml and added those two new keys, along with sig helper and adding signature_server: inv_sig_helper:12999 as well.

inv_sig_helper: image: quay.io/invidious/inv-sig-helper:latest command: ["--tcp", "0.0.0.0:12999"] environment: - RUST_LOG=info restart: unless-stopped cap_drop: - ALL read_only: true security_opt: - no-new-privileges:true

observations:

  1. If no account is logged into the instance, every video plays.
  2. if you're logged into an existing account with subs/playlists, no video plays.
  3. if you create a brand new account, with no subs or playlists, every video plays.
  4. if you export invidious settings from import/export under settings, and import into the new account you just created, no video plays.

items # 3. and 4. have thrown me off in a loop. Not sure what is causing that. Any clues on what could be the reason?

Thank you all for your incredible hard work!! we shall prevail!! :)

@DUOLabs333 yes I have it in my docker compose yaml. I even tried using the exact same compose file in the documentation and it's still the same. I also tried using a fresh backend but it didn't do anything.

MSWS commented

If anyone wants to keep rotating the tokens, I wrote this small script which you can run in a cronjob:

output=$(docker run quay.io/invidious/youtube-trusted-session-generator)

visitor_data=$(echo "$output" | awk -F': ' '/visitor_data/ {print $2}')
po_token=$(echo "$output" | awk -F': ' '/po_token/ {print $2}')

sed -i "s/visitor_data:.*/visitor_data: $visitor_data/" docker-compose.yml
sed -i "s/po_token:.*/po_token: $po_token/" docker-compose.yml

docker compose up -d invidious

A small enhancement I made to this script allows for specifying these variables in a .env instead of in the compose directly. Also added the --rm flag so we don't create a dangling container every time.

#!/usr/bin/env bash

output=$(docker run --rm quay.io/invidious/youtube-trusted-session-generator)

visitor_data=$(echo "$output" | awk -F': ' '/visitor_data/ {print $2}')
po_token=$(echo "$output" | awk -F': ' '/po_token/ {print $2}')

sed -i "s/VISITOR_DATA=.*/VISITOR_DATA=$visitor_data/" [PATH]/.env
sed -i "s/PO_TOKEN=.*/PO_TOKEN=$po_token/" [PATH]/.env

docker compose -f [PATH]/compose.yml up --force-recreate -d
DX37 commented

Any idea how to combine this inv_sig_helper with gluetun?

Have the same 403 issue as everyone else with an docker install. Started a few days ago. Added inv-sig-helper and that gets Medium/HD720/Small working with but not DASH. Proxy videos has no effect.

I'm having the same issue, and Debian stable doesn't have new enough rust to build inv-sig-helper. Is there another workaround?

Install rust & cargo locally:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

after try add inv_sig and run it on docker still have getting same error.

Have the same 403 issue as everyone else with an docker install. Started a few days ago. Added inv-sig-helper and that gets Medium/HD720/Small working with but not DASH. Proxy videos has no effect.

@porchthecoder Same issue. But if I set my account default to DASH, it gives the format no supported error. Setting the default to medium will play all videos at medium.

Logging out of my account within invidious didn't help the problem in my case.
And I doubt it'd block my IP since my ISP rotates them daily - unless they're linking that up with the token stuff...
Unlike for some other people here, changing the quality settings hasn't worked out for me either. Neither has setting up the tokens and the sig helper.
Quite unfortunate really...

Same error here in docker.
po_token and visitor_data are set in the yml and so is the signature_server.

I tested different compose configurations (included with and without the po_token/visitor_data , rotating them too) and I still get:

2024-09-28 10:25:42 UTC [info] 403 GET /videoplayback?expire=1727540741&ei=pdn3ZrbODIKP6dsPk82eyAs&ip=87.121.148.217&id=o-APGzA0C1oqM4PkDVl4OIu0Cd7EQMvvmDXAwPLUSRuVWm&itag=396&aitags=133%2C134%2C135%2C136%2C137%2C160%2C242%2C243%2C244%2C247%2C248%2C278%2C394%2C395%2C396%2C397%2C398%2C399&source=youtube&requiressl=yes&xpc=EgVo2aDSNQ%3D%3D&mh=hP&mm=31%2C26&mn=sn-hpa7knle%2Csn-4g5edndd&ms=au%2Conr&mv=m&mvi=1&pl=23&initcwndbps=2930000&bui=AXLXGFR8-GTFkbdfC82uOk4TZut_1hbJy9Jw8HQgFQSWjM94zk29xOthtGQ4tizya4fcnZW8biDcUpcb&vprv=1&svpuc=1&mime=video%2Fmp4&ns=yWhK_XJle9gFgDx-3FCP0GEQ&rqh=1&gir=yes&clen=7257892&ratebypass=yes&dur=520.520&lmt=1727365109973585&mt=1727518619&fvip=4&keepalive=yes&fexp=51299152&c=TVHTML5_SIMPLY_EMBEDDED_PLAYER&sefc=1&txp=5537434&n=YeseYD5qhYc8IwsxR&sparams=expire%2Cei%2Cip%2Cid%2Caitags%2Csource%2Crequiressl%2Cxpc%2Cbui%2Cvprv%2Csvpuc%2Cmime%2Cns%2Crqh%2Cgir%2Cclen%2Cratebypass%2Cdur%2Clmt&sig=AJfQdSswRgIhAN73IRFTvQOWPvpcpSwzAWkxAvmtKHw0qAE9w0spqpD_AiEAq-0feNGsWh4hCrXwfvp97-Pt8AgKtF17yGlVaEHa2TA%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=ABPmVW0wRQIgCrPPsoMTU0Bh9MeL0A4ujdXZlgJayRB3-PR-16ICWPgCIQC64Au3nR6FdP3K7pf1MgrUXakkGzWMVAsi-3BlpxrT4w%3D%3D&host=rr1---sn-hpa7knle.googlevideo.com 204.29ms

Hi any solution for the killer bug?

Hello I added the signature helper but most videos still don't work and I get 403 GET /videoplayback error. Weirdly enough I found that MKBHD videos work with a 206 GET /videoplayback status but anything else does not.

Signature helper at log startup

inv_sig_helper-1  | [2024-09-26T00:00:29Z INFO  inv_sig_helper_rust] Fetching player
inv_sig_helper-1  | [2024-09-26T00:00:30Z INFO  inv_sig_helper_rust::player] Fetching player JS URL: https://www.youtube.com/s/player/c9dd45ed/player_ias.vflset/en_US/base.js
inv_sig_helper-1  | [2024-09-26T00:00:30Z WARN  inv_sig_helper_rust::player] nsig function ending did not work: =\s*function(\([\w]+\)\{\s*var\s+[\w\s]+=[\w\.\s]+?\.call\s*\([\w\s$]+?,[\(\)\",\s]+\)[\S\s]*?\}\s*return [\w\.\s$]+?\.call\s*\([\w\s$]+?\s*,[\(\)\",\s]+\)\s*\}\s*;)
inv_sig_helper-1  | [2024-09-26T00:00:30Z INFO  inv_sig_helper_rust::player] sig code: var iCa;var iL={Z2:function(a,b){a.splice(0,b)},
inv_sig_helper-1  |     h5:function(a){a.reverse()},
inv_sig_helper-1  |     YZ:function(a,b){var c=a[0];a[0]=a[b%a.length];a[b%a.length]=c}};iCa=function(a){a=a.split("");iL.h5(a,0);iL.Z2(a,3);iL.YZ(a,4);iL.YZ(a,25);iL.h5(a,21);iL.Z2(a,2);iL.YZ(a,17);iL.YZ(a,29);return a.join("")}
inv_sig_helper-1  | [2024-09-26T00:00:30Z INFO  inv_sig_helper_rust] Successfully fetched player

Update
I usually run the invidious container on Unraid but since it wasn't working I used the updated docker compose yaml in a vm and now it works. Its the same compose file with the same db data. The only thing that is different is where its running. Anyone have any ideas on how to debug this further and why running it Unraid would cause problems?

Hey,

I just commented out the po_token and visitor_data in my docker compose file - and somehow it seems to be working as expected now.

I am not sure why this is closed or marked as complete @unixfox .
As per my comment here for example, I have po_token and visitor_data set but the error still persists.

403 GET /videoplayback?expire=1727643547&ei=O2v5ZpTNBe6wi9oPgayuuQs&ip=87.121.148.217&id=o-AE1wSeMnUL6g75RS4mWdMMhx1WpM_fD3TGH1hLXQj99x&itag=18&source=youtube&requiressl=yes&xpc=EgVo2aDSNQ%3D%3D&mh=0B&mm=31%2C26&mn=sn-hpa7znzr%2Csn-4g5lznek&ms=au%2Conr&mv=m&mvi=4&pl=23&initcwndbps=2261250&bui=AXLXGFSrUL9k8cOd9C_YSaox-cDfSnZkca3WyiBDxgj4WJvIiK-mmOJuHbmfKZRB-quwclR4mRF6hKXK&vprv=1&svpuc=1&mime=video%2Fmp4&ns=T3mmiwabOGmsiJKWCOS9V_IQ&rqh=1&gir=yes&clen=58239657&ratebypass=yes&dur=845.067&lmt=1727496060449986&mt=1727621597&fvip=3&fexp=51299152%2C51300760&c=TVHTML5_SIMPLY_EMBEDDED_PLAYER&sefc=1&txp=4438434&n=6eWZ4RIdGbq6RYTaD&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cxpc%2Cbui%2Cvprv%2Csvpuc%2Cmime%2Cns%2Crqh%2Cgir%2Cclen%2Cratebypass%2Cdur%2Clmt&sig=AJfQdSswRAIgARc5LJ3A8DikDlca5EMDbAhXCayqBqBL_4C6tYSGQnsCIGN0lMMqtPAToeAok1SDzt951xzvF634voE53tizzMyy&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=ABPmVW0wRAIfeJNa4UEHr_2uWB9kH4lcbe5g5FBQ3SLoDM8wrpkAvAIhAJ8k9f6fvuFEr9Q2RXuEFLqQd9juG5A0j9ST280VerD_&host=rr4---sn-hpa7znzr.googlevideo.com 273.79ms

Do you mean that if my IP is blocked (a domestic one tho), the error will persist even with the po_token method? For reference, also with a VPN it does not work: I assume youtube would not block all the VPNs so maybe I am doing something wrong.

@tcsenpai If you have thoroughly followed the official guide, which includes generating a po_token, visitor_data AND configuring the inv_sig_helper like explained in https://docs.invidious.io/installation/

Then I'm sorry for the moment there is nothing else that you can do. Your IP has probably been blocked by YouTube.

@tcsenpai If you have thoroughly followed the official guide, which includes generating a po_token, visitor_data AND configuring the inv_sig_helper like explained in https://docs.invidious.io/installation/

Then I'm sorry for the moment there is nothing else that you can do. Your IP has probably been blocked by YouTube.

Oh ok, sad to hear that. I tried with every IP could try with (one domestic and the others with a VPN) and I am still unable to have a working video. Yes I configured inv_sig_helper in the docker and generated the token and data indeed.

Weird enough, with the same VPN and IP I am using in gluetun i can access the normal youtube frontend just fine.

UPDATE: I moved both gluetun and invidious to another home server I have (same model , same network, same ip as the other). Now everything works.

NOTE: To use gluetun and the sig_helper container together on the new server I had to assign to the sig_helper container in the docker-compose.yml file a gluetun network address and edit it above.

Example:

In docker-compose.yml

invidious:
    [...]
    environment:
    [...]
      signature_server: 172.80.0.32

[....]

inv_sig_helper:
    [...]
    networks:
      gluetun_network:
        172.80.0.32
[....]

@tcsenpai If you have thoroughly followed the official guide, which includes generating a po_token, visitor_data AND configuring the inv_sig_helper like explained in https://docs.invidious.io/installation/
Then I'm sorry for the moment there is nothing else that you can do. Your IP has probably been blocked by YouTube.

Oh ok, sad to hear that. I tried with every IP could try with (one domestic and the others with a VPN) and I am still unable to have a working video. Yes I configured inv_sig_helper in the docker and generated the token and data indeed.

Weird enough, with the same VPN and IP I am using in gluetun i can access the normal youtube frontend just fine.

UPDATE: I moved both gluetun and invidious to another home server I have (same model , same network, same ip as the other). Now everything works.

NOTE: To use gluetun and the sig_helper container together on the new server I had to assign to the sig_helper container in the docker-compose.yml file a gluetun network address and edit it above.

Example:

In docker-compose.yml

invidious:
    [...]
    environment:
    [...]
      signature_server: 172.80.0.32

[....]

inv_sig_helper:
    [...]
    networks:
      gluetun_network:
        172.80.0.32
[....]

may be they are blocking by MAC ADDRESS ?

@tcsenpai If you have thoroughly followed the official guide, which includes generating a po_token, visitor_data AND configuring the inv_sig_helper like explained in https://docs.invidious.io/installation/
Then I'm sorry for the moment there is nothing else that you can do. Your IP has probably been blocked by YouTube.

Oh ok, sad to hear that. I tried with every IP could try with (one domestic and the others with a VPN) and I am still unable to have a working video. Yes I configured inv_sig_helper in the docker and generated the token and data indeed.
Weird enough, with the same VPN and IP I am using in gluetun i can access the normal youtube frontend just fine.
UPDATE: I moved both gluetun and invidious to another home server I have (same model , same network, same ip as the other). Now everything works.
NOTE: To use gluetun and the sig_helper container together on the new server I had to assign to the sig_helper container in the docker-compose.yml file a gluetun network address and edit it above.
Example:
In docker-compose.yml

invidious:
    [...]
    environment:
    [...]
      signature_server: 172.80.0.32

[....]

inv_sig_helper:
    [...]
    networks:
      gluetun_network:
        172.80.0.32
[....]

may be they are blocking by MAC ADDRESS ?

I don't think so because both my servers are behind the same router (which also has a static IP), thus their mac addresses shouldn't hit the web.

I would blame some sort of reused resource by docker but I am not enough proficient to elaborate more

@tcsenpai If you have thoroughly followed the official guide, which includes generating a po_token, visitor_data AND configuring the inv_sig_helper like explained in https://docs.invidious.io/installation/
Then I'm sorry for the moment there is nothing else that you can do. Your IP has probably been blocked by YouTube.

Oh ok, sad to hear that. I tried with every IP could try with (one domestic and the others with a VPN) and I am still unable to have a working video. Yes I configured inv_sig_helper in the docker and generated the token and data indeed.
Weird enough, with the same VPN and IP I am using in gluetun i can access the normal youtube frontend just fine.
UPDATE: I moved both gluetun and invidious to another home server I have (same model , same network, same ip as the other). Now everything works.
NOTE: To use gluetun and the sig_helper container together on the new server I had to assign to the sig_helper container in the docker-compose.yml file a gluetun network address and edit it above.
Example:
In docker-compose.yml

invidious:
    [...]
    environment:
    [...]
      signature_server: 172.80.0.32

[....]

inv_sig_helper:
    [...]
    networks:
      gluetun_network:
        172.80.0.32
[....]

may be they are blocking by MAC ADDRESS ?

I don't think so because both my servers are behind the same router (which also has a static IP), thus their mac addresses shouldn't hit the web.

I would blame some sort of reused resource by docker but I am not enough proficient to elaborate more

Deleted all containers and recompiled/installed the stuff again same error.

Oh, I think it does work, but cached videos (even those that were opened unsuccessfully) are not sent to the helper.

Yeah, truncation was needed (I remembered the command --- psql -d invidious -c 'TRUNCATE TABLE videos')

Are you managing your containers in Portainer?

No, I use my own scripts.

In case anyone is using docker and this can help, I used this command to truncate the videos table in docker which allowed me to view previously failed videos:

 docker exec invidious-invidious-db-1 psql -U kemal -d invidious -c 'TRUNCATE TABLE videos'

Adding to the thread - went through the process of running the session generator via docker run quay.io/invidious/youtube-trusted-session-generator, got the two keys

  • po_token
  • visitor_data identities

plugged them into docker-compose.yml and added those two new keys, along with sig helper and adding signature_server: inv_sig_helper:12999 as well.

inv_sig_helper: image: quay.io/invidious/inv-sig-helper:latest command: ["--tcp", "0.0.0.0:12999"] environment: - RUST_LOG=info restart: unless-stopped cap_drop: - ALL read_only: true security_opt: - no-new-privileges:true

observations:

  1. If no account is logged into the instance, every video plays.
  2. if you're logged into an existing account with subs/playlists, no video plays.
  3. if you create a brand new account, with no subs or playlists, every video plays.
  4. if you export invidious settings from import/export under settings, and import into the new account you just created, no video plays.

items # 3. and 4. have thrown me off in a loop. Not sure what is causing that. Any clues on what could be the reason?

Thank you all for your incredible hard work!! we shall prevail!! :)

did anyone ever answer that?