yt-dlp: [Youtube] Did not get any data blocks for format 22

…and solved.

Got a hint from this that the issue was downloading mp4 in some cases, so I listed the formats and chose a webm stream instead. Then it worked.

~$ yt-dlp --list-formats https://www.youtube.com/watch?v=GnXk6Pex0SE 

[youtube] GnXk6Pex0SE: Downloading webpage
[youtube] GnXk6Pex0SE: Downloading android player API JSON
[info] Available formats for GnXk6Pex0SE:
ID  EXT   RESOLUTION FPS │   FILESIZE   TBR PROTO │ VCODEC        VBR ACODEC      ABR     ASR MORE INFO
────────────────────────────────────────────────────────────────────────────────────────────────────────────────
sb2 mhtml 48x27          │                  mhtml │ images                                    storyboard
sb1 mhtml 80x45          │                  mhtml │ images                                    storyboard
sb0 mhtml 160x90         │                  mhtml │ images                                    storyboard
139 m4a   audio only     │    4.50MiB   48k https │ audio only        mp4a.40.5   48k 22050Hz low, m4a_dash
249 webm  audio only     │    4.63MiB   50k https │ audio only        opus        50k 48000Hz low, webm_dash
250 webm  audio only     │    5.99MiB   64k https │ audio only        opus        64k 48000Hz low, webm_dash
140 m4a   audio only     │   11.95MiB  129k https │ audio only        mp4a.40.2  129k 44100Hz medium, m4a_dash
251 webm  audio only     │   11.05MiB  119k https │ audio only        opus       119k 48000Hz medium, webm_dash
17  3gp   176x144      6 │    7.62MiB   82k https │ mp4v.20.3     82k mp4a.40.2    0k 22050Hz 144p
160 mp4   256x144     25 │    7.45MiB   80k https │ avc1.4d400c   80k video only              144p, mp4_dash
278 webm  256x144     25 │    7.47MiB   80k https │ vp9           80k video only              144p, webm_dash
133 mp4   426x240     25 │   15.89MiB  172k https │ avc1.4d4015  172k video only              240p, mp4_dash
242 webm  426x240     25 │   13.33MiB  144k https │ vp9          144k video only              240p, webm_dash
134 mp4   640x360     25 │   29.41MiB  318k https │ avc1.4d401e  318k video only              360p, mp4_dash
18  mp4   640x360     25 │   45.91MiB  497k https │ avc1.42001E  497k mp4a.40.2    0k 44100Hz 360p
243 webm  640x360     25 │   22.90MiB  248k https │ vp9          248k video only              360p, webm_dash
135 mp4   854x480     25 │   63.53MiB  688k https │ avc1.4d401e  688k video only              480p, mp4_dash
244 webm  854x480     25 │   37.29MiB  404k https │ vp9          404k video only              480p, webm_dash
136 mp4   1280x720    25 │  119.43MiB 1294k https │ avc1.64001f 1294k video only              720p, mp4_dash
22  mp4   1280x720    25 │ ~ 96.75MiB 1023k https │ avc1.64001F 1023k mp4a.40.2    0k 44100Hz 720p
247 webm  1280x720    25 │   69.13MiB  749k https │ vp9          749k video only              720p, webm_dash
298 mp4   1280x720    50 │  153.51MiB 1663k https │ avc1.640020 1663k video only              720p50, mp4_dash
302 webm  1280x720    50 │  107.75MiB 1167k https │ vp9         1167k video only              720p50, webm_dash
299 mp4   1920x1080   50 │  269.23MiB 2917k https │ avc1.64002a 2917k video only              1080p50, mp4_dash
303 webm  1920x1080   50 │  200.36MiB 2171k https │ vp9         2171k video only              1080p50, webm_dash

~$ yt-dlp -f 303 --no-continue https://www.youtube.com/watch?v=GnXk6Pex0SE

[youtube] GnXk6Pex0SE: Downloading webpage
[youtube] GnXk6Pex0SE: Downloading android player API JSON
[info] GnXk6Pex0SE: Downloading 1 format(s): 303
[download] Destination: Modifying a Harley Benton Jazzmaster Kit _ #DIYKitChallenge22 Part 1 [GnXk6Pex0SE].webm
[download] 100% of 200.36MiB in 00:21

The problem is that youtube is serving broken formats. Sometimes you can pass --check-formats to workaround this, and if the link is broken from the get-go, then yt-dlp will automatically select the “next best” format. However, if the format is broken in the middle of the file, then there is nothing we can really do.

There is no way for the extractor or the format-checking code to know ahead of time that the format is bad in the middle. There is no way for the downloader to know that the format is actually broken or if this is merely a transient network issue. In this case, you need to work around the issue yourself by manually selecting a different format.

Unless someone has a specific implementation idea on how to drastically improve yt-dlp core code to handle this, or how to detect broken Youtube formats in advance, then IMO there is no point in continuing this conversation.

Facing same problem with broken 22 in my own script I resorted to this kludge:

XmlHttpRequest({
	method:'GET',
	headers: {
		range: 'bytes=' + (videoList[lastItag].size - 100200) + '-' + (videoList[lastItag].size - 100100)
	},
	url:videoList[lastItag].url,
	onload:function(response) {
		if (response.readyState != 4 || response.status != 206) {
			console.log('Theoretically not expired, but still invalid URL. Refetching is useless, downgrading.')

tldr: start by trying to download 100 bytes from last 100KB of file. YT broken 22 files usually break either at the start or middle, I dont remember ever experiencing one that would refuse to play last couple seconds.

Does anyone have any theories as to why YouTube is delivering broken “format 22” fragments, that always fail in the same place? Is this a new thing in the last couple years — that they might be well aware of — and might be willing to fix and/or doing on purpose?

IMO its the combination of those three: 1 composite formats got deprioritized once they had dynamic switching in the player. No one ever looks if if infra is working anymore 2 In theory only old legacy outdated unpatched clients use 22, breaking it randomly will nudge those people to upgrade. 3 https://www.zdnet.com/article/former-mozilla-exec-google-has-sabotaged-firefox-for-years/

Formats 17, 18 and 22 are legacy formats. Your web browser is never gonna play these. They are not a priority for Youtube to fix. Format 17 was completely removed a few weeks ago, even

It certainly is one in regard to biting me away from here. Noted.

Formats 17, 18 and 22 are legacy

Interesting 🤔

It would be nice if there was a way to filter out 17, 18, and 22. I couldn’t see in the documentation a way to skip or sort specific format numbers

If you start getting zero-byte segments then drop the existing format as invalid, then go back and restart the process from a different format.

Closing since the issue seems to have fixed itself. Even if not, we have had no reason to believe there is a way to work around the issue

what’s worse is yt-dlp is recording the broken download in the archive (so it doesn’t try redownloading during next run),

Open a new issue with all relevant details including verbose log

Format 22 is identical to 136+140, and it is not even served in the browser anymore by youtube. Besides, the point here is that the format is broken from YouTube’s side. There is nothing that can be done about it

@YellowSM mp4[height<=720] means best[ext=mp4][height<=720], which is why it selects 22. What you want is -S res:720,ext

I’m stating the obvious here, but I still want to throw this in. Format 22 in likely the most popular. It provides the best balance between quality and size.

@someziggyman From my observation it seems recently uploaded videos take some time to get format 22 downloadable.