[FIXED IN 0.23.2] [YouTube] "The following content is not available on this app." message shown in video/5 minutes of silence instead of a sound

[Milkdrop]

Checklist

• I am able to reproduce the bug with the latest version.
• I made sure that there are no existing issues - open or closed - which I could contribute my information to.
• I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• This issue contains only one bug.
• I have read and understood the contribution guidelines.

Affected version

0.23.1

Steps to reproduce the bug

1. Go to penguinz0's "Biggest scandal I've ever seen" video (https://www.youtube.com/watch?v=7-BqJKE14Yo)
2. Play it at 360p resolution

Expected behavior

The video should play normally

Actual behavior

The message "The following content is not available on this app. Watch this content on the latest version on YouTube" appears.

Screenshots/Screen recordings

Logs

No response

Affected Android/Custom ROM version

Android 11 / ArrowOS 11

Affected device model

ASUS ZenFone Max Pro M1

Additional information

No response

[LuanRT]

I noticed this also happens in older versions of official clients, and it's quite random. So YouTube is probably rolling out some sort of update.

For those who haven't seen yet: https://support.google.com/youtube/answer/12318250?hl=en-US

Similar issues:
iv-org/invidious#3230

[AudricV]

Yes, that's random because when I try to play the video, it works for me. So seems to be a A/B test or a very slow rollout for me.

A workaround you can use for now is to block the youtubei.googleapis.com domain on NewPipe, which will prevent the extractor to use Android and iOS clients, and make only use of the desktop web client.

You can also try to clear metadata in cache from History and cache settings.

We should update the client version used to the latest one (17.29.34 on Android and 17.29.3 on iOS currently) and see if the issue happens. If so, unfortunately, we would have to remove usage of other clients than the HTML5 ones or make better spoofing of the mobile clients.

We use right now the 17.10.35 version, as you can see here.

[coletdjnz]

Seems like changing the app version may not suffice.

If this is to be believed, we need to get our hands on a reproducible environment for us to test on.

Since this appears to be an A/B Innertube API test, I'm assuming it is tied to vistorData.

If someone can get their hands on either:

• visitorData string (X-Goog-Visitor-Id header, or visitorData string in the context of an API request or in the responseContext of an API response)
• VISITOR_INFO1_LIVE cookie

from a request or session that experiences this it might be helpful in creating a reproducible environment.

[unixfox]

@coletdjnz Could the API key used in Newpipe be outdated too?

[AudricV]

According to my tests, the visitor data (at least in the header), user-agent, API key, t and id parameters of the player request does not have an effect on URLs: everything seems to be related to the protobuf body sent.

Could the API key used in Newpipe be outdated too?

No, the API key used is still the same, as you can see on this capture made by mitmproxy:

[unixfox]

If this is to be believed, we need to get our hands on a reproducible environment for us to test on.

I have a visitorData ID that was able to produce the issue, I've packed a bunch of info in that gist: https://gist.github.com/unixfox/a7ba15fa9b71ab302f7eebf7aa876563. Do note that this visitorData ID seems to be tied to the IP address.

Here is my dirty script for continuously checking the hash of a YouTube video: https://gist.github.com/unixfox/10a3f4e5a8499059ff18ad8d6b260585

I replicated the issue on a Digitalocean droplet in UK location with IPv6 disabled and the DNS server set to 8.8.8.8 if one wants to have an environment to the one that I used. Outbound traffic is free on Digitalocean.

EDIT: I can't reproduce the issue on the client ANDROID_EMBEDDED_PLAYER and IOS. I took these client names from https://github.com/zerodytrash/YouTube-Internal-Clients

[unixfox]

Through trial and errors, I just found in the protobuf player request that the parameter needed to not have the error The Following content is not available on this app. is this one:

64: 29

In the protobuf decoded raw request (cat tmp.pb | protoc --decode_raw):

1 {
  1 {
    16: 3
    17: "17.29.34"
    64: 29
  }
}
2: "c7NdXldReAg"

Here is another preview of the protobuf decoded raw request from this tool https://github.com/nevermoe/protobuf_decoder:

{
    "01:00:embedded message": {
        "01:00:embedded message": {
            "16:02:Varint": 3, 
            "17:03:string": "17.29.34",
            "64:20:Varint": 29
        }
    }, 
    "02:01:string": "c7NdXldReAg"
}

The issue is that I've no idea what's the name of the 64th element of the context => client object, so that we can use it in a JSON request.

In summary:

• 1 is context
• 1 => 1 is context => client
• 1 => 1 => 16 is context => client => "ANDROID"
• 1 => 1 => 17 is context => client => "17.29.34"
• 2 is videoId

I've uploaded the protobuf file here: protobuf.zip

I'll continue my research, but if more people can help me in finding that parameter, that would be great.

[LuanRT]

The issue is that I've no idea what's the name of the 64th element of the context => client object, so that we can use it in a JSON request.

I've seen seen this parameter multiple times before — isn't it the Android API level?

Ex:

1 {
  1 {
    12: "Google"
    13 {
      6: 0x45303130
    }
    16: 3
    17: "17.26.32"
    18: "Android"
    19: "6.0"
    21 {
      12: 0x53552d6e
    }
    37: 320
    38: 569
    39: 0x40000000
    40: 0x4063bbbc
    41: 2
    46: 1
    50: 222613015
    55: 320
    56: 569
    61: 3
    64: 23 // 23 is Android 6.0
    65: 0x3fc00000
    67: 18446744073709551436
    80: "America/Sao_Paulo"
  }
}

So, if all they're doing is checking the OS version then maybe we could just use the osVersion param in JSON requests?

Edit:
Could also be osApiLevel, if that even exists.

[unixfox]

So, if all they're doing is checking the OS version

You are correct, I'm on Android 10 and the API level is 29.

then maybe we could just use the osVersion param in JSON requests?

Edit: Could also be osApiLevel, if that even exists.

Just tested, both osVersion and osApiLevel doesn't work, osVersion is probably the 19th parameter. I think it's more something like platformXXX, it's not platformVersion nor platformApiLevel.

---

I think it's sdk something because when MITM the requests done by the app I find again that 29 android API level:

https://www.youtube.com/csi_204?v=3
s=youtube_android
action=home_with_thumbnails
yt_lt=warm
th0_tt=1
conn=3
cplatform=mobile
cbr=com.google.android.youtube
cff=SMALL_FORM_FACTOR
c=android
cplayer=ANDROID_EXOPLAYER_V2
cmodel=SM-G930F
cos=Android
csdk=29
cbrver=17.29.34
cver=17.29.34
cosver=10
cbrand=samsung
proc=8

[SamantazFox]

@unixfox have you tried clientSDK, platformSDK, or even just SDK?

Btw, I've gathered my current knowledge of the protobuf to parameter name mapping here:
https://gist.github.com/SamantazFox/be4a0f224b179c544d7dac85768fdd12

[unixfox]

@unixfox have you tried clientSDK, platformSDK, or even just SDK?

Btw, I've gathered my current knowledge of the protobuf to parameter name mapping here: gist.github.com/SamantazFox/be4a0f224b179c544d7dac85768fdd12

Yes doesn't work. The issue is that the parameter name is case-sensitive... that makes everything much more much difficult

[Prototaxis]

@unixfox Give androidSdkVersion a try. I found it in the youtube app headers over here: https://github.com/thelazyitguy/AppHeaders/blob/36333bdff322f80a5895d7441f4cdf68637812fa/YouTube%2015.45.2/YTIClientInfo.h

[unixfox]

@unixfox Give androidSdkVersion a try. I found it in the youtube app headers over here: thelazyitguy/AppHeaders@36333bd/YouTube%2015.45.2/YTIClientInfo.h

Thank you @Prototaxis! That's the correct parameter name! I don't get the error anymore.

[Prototaxis]

I'm glad it worked. Thanks @coletdjnz for forwarding me to this thread.