[Bug] The video returned by YouTube isn't the requested one. (WEB client) (VideoNotAvailableException)

For everyone:

We are fully aware of this issue, please comment only if you have new info to bring on. Please refrain from opening new issues.
YouTube has recently started to care about alternative frontends like Invidious and is trying to block them.
This currently only affects some public Invidious instances, so if you have the resources, we recommend installing Invidious on your own personal computer or server: https://docs.invidious.io/installation/

Otherwise, try to find another working instance from the list: https://instances.invidious.io

For Invidious instance maintainers:

We have officially released a tool that allow to automatically rotate the IPv6 address of your Invidious server: iv-org/smart-ipv6-rotator and thus escape from the YouTube block!

You can follow the detailed tutorial here: docs.invidious.io/ipv6-rotator

If you want to discuss or read for other solutions: #3915

---

BUG: The video returned by YouTube isn't the requested one. (WEB client) (VideoNotAvailableException)

When trying to loading any video on the invidious.vpsburti.com instance, this error is shown:

Title: `The video returned by YouTube isn't the requested one. (WEB client) (VideoNotAvailableException)`
Date: `2023-05-27T08:21:28Z`
Route: `/watch?v=Nx-ougrNm50&listen=1`
Version: `2023.05.14-3a54e95 @ master`

<details>
<summary>Backtrace</summary>
<p>

The video returned by YouTube isn't the requested one. (WEB client) (VideoNotAvailableException)
  from /usr/share/crystal/src/array.cr:114:31 in 'extract_video_info:video_id'
  from src/invidious/videos.cr:377:10 in 'fetch_video'
  from src/invidious/videos.cr:365:13 in 'get_video:region'
  from src/invidious/routes/watch.cr:63:15 in 'handle'
  from lib/kemal/src/kemal/route.cr:13:9 in '->'
  from src/invidious/helpers/handlers.cr:30:37 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from lib/kemal/src/kemal/filter_handler.cr:21:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from lib/kemal/src/kemal/init_handler.cr:12:7 in 'process'
  from /usr/share/crystal/src/http/server.cr:500:5 in '->'
  from /usr/share/crystal/src/fiber.cr:146:11 in 'run'
  from ???
</p>
</details>

[unixfox]

It appears that YouTube is doing some breaking changes in a rollout way, which means it doesn't affect all the instances.

I'm trying to find an affected IP address where I could debug the issue. For now it seems like people that are hosted at hetzner (invidious.nerdvpn.de & invidious.vpsburti.com) are affected.

[dellasorte]

I've got this as well

Title: The video returned by YouTube isn't the requested one. (WEB client) (VideoNotAvailableException)
Date: 2023-05-27T06:08:04Z
Route: /watch?v=QncYBP785uA
Version: 2023.05.25-381a0e3 @ master

Backtrace

The video returned by YouTube isn't the requested one. (WEB client) (VideoNotAvailableException)
  from /usr/share/crystal/src/array.cr:114:31 in 'extract_video_info:video_id'
  from src/invidious/videos.cr:377:10 in 'fetch_video'
  from src/invidious/videos.cr:365:13 in 'get_video:region'
  from src/invidious/routes/watch.cr:63:15 in 'handle'
  from lib/kemal/src/kemal/route.cr:13:9 in '->'
  from src/invidious/helpers/handlers.cr:30:37 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from lib/kemal/src/kemal/filter_handler.cr:21:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:28:7 in 'call_next'
  from lib/kemal/src/kemal/init_handler.cr:12:7 in 'process'
  from /usr/share/crystal/src/http/server.cr:500:5 in '->'
  from /usr/share/crystal/src/fiber.cr:146:11 in 'run'
  from ???

[unixfox]

You can solve this issue by changing the IP address of your server.

Nowadays, you get IPv6 on most server providers. Try curl -I -6 ipv6.google.com and if you don't get any error, you have ipv6. If not, try to get a new IPv4 address.

If you are on Docker

Very easily solution based on the docker-compose provided in the documentation

Adapt this example docker-compose to your current docker-compose configuration:

version: "3"
services:

  ipv6nat:
    container_name: ipv6nat
    privileged: true
    network_mode: host
    restart: unless-stopped
    volumes:
      - '/var/run/docker.sock:/var/run/docker.sock:ro'
      - '/lib/modules:/lib/modules:ro'
    image: robbertkl/ipv6nat

  invidious:
    image: quay.io/invidious/invidious:latest
    # image: quay.io/invidious/invidious:latest-arm64 # ARM64/AArch64 devices
    restart: unless-stopped
    networks:
      - invidious
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      # Please read the following file for a comprehensive list of all available
      # configuration options and their associated syntax:
      # https://github.com/iv-org/invidious/blob/master/config/config.example.yml
      INVIDIOUS_CONFIG: |
        db:
          dbname: invidious
          user: kemal
          password: kemal
          host: invidious-db
          port: 5432
        check_tables: true
        # external_port:
        # domain:
        # https_only: false
        # statistics_enabled: false
    healthcheck:
      test: wget -nv --tries=1 --spider http://127.0.0.1:3000/api/v1/comments/jNQXAC9IVRw || exit 1
      interval: 30s
      timeout: 5s
      retries: 2
    logging:
      options:
        max-size: "1G"
        max-file: "4"
    depends_on:
      - invidious-db

  invidious-db:
    image: docker.io/library/postgres:14
    restart: unless-stopped
    networks:
      - invidious
    volumes:
      - postgresdata:/var/lib/postgresql/data
      - ./config/sql:/config/sql
      - ./docker/init-invidious-db.sh:/docker-entrypoint-initdb.d/init-invidious-db.sh
    environment:
      POSTGRES_DB: invidious
      POSTGRES_USER: kemal
      POSTGRES_PASSWORD: kemal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB"]

volumes:
  postgresdata:

networks:
  invidious:
    name: invidious
    enable_ipv6: true
    ipam:
      config:
        - subnet: fd00:dead:beec::/48

The major changes are networks:, adding invidious and invidious-db to the invidious network and adding the service ipv6nat.

Then if execute this command and if you get a ping reply then everything is working fine:

docker compose exec -u root invidious ping -c 2 ipv6.google.com

The downside of this option is that you are running a separate service in privileged mode, and this is not great for security. If possible, I would recommend following the official documentation below.

Or the official way using the Docker documentation for IPv6

Or you can also take a look at the official Docker documentation for IPv6, which explains the official way to configure IPv6 on Docker:

• https://docs.docker.com/config/daemon/ipv6/
• https://gdevillele.github.io/engine/userguide/networking/default_network/ipv6/

Not on Docker

If you already have IPv6, then you can try to use IPv4 by switching this parameter in the config.yml (found here):

force_resolve: ipv4

Or try the tips below about ipv6.

Apply for both Docker and not Docker

If you can replicate the issue again on IPv6, try to add a new IPv6 address. Use ip a and check if your IPv6 address doesn't end with /128 then you are in luck.
You can then try to add a new IPv6 address using this tutorial: https://tldp.org/HOWTO/Linux+IPv6-HOWTO/ch06s02.html. All you want to do is to change just a number or a letter, example:

2001:0db8:0:f101::1/64 to 2001:0db8:0:f101::2/64

Or you can try to switch back to IPv4 by switching this parameter in the config.yml (found here):

force_resolve: ipv4

[unixfox]

After a bit more dinging into the issue, I've found that even on the official www.youtube.com website you get the error:

I'm not sure if it's an error on their side or a way to "shadow ban" an IP address. For now I don't have a solution except using another IP address like described above.

Another instance that started having the same problems a couple of hours ago:
invidious.nogafa.org
Judging by Whois, it is hosted on OVH SAS.
This state of affairs is already starting to worry me, because if Google continues to ban VPS/VDS providers, then I'm afraid that over time, every Invidious instance will not work anymore.

[lo2dev]

Started noticing the same errors today as well at https://invidious.sethforprivacy.com