ERROR: Did not get any data blocks

[ghost]

This error occurs pretty frequently, usually with videos that have low views starting around 2013-04-16 12:00:00 GMT. Here's a single example. I'm using ec2 on us-west2.

UPDATE: The issue is no longer occurring. Does anyone have any idea what the "ERROR: content too short" can mean?

$ youtube-dl -f 18 http://www.youtube.com/watch?v=lix0A-F6bz4
[youtube] Setting language
[youtube] lix0A-F6bz4: Downloading video webpage
[youtube] lix0A-F6bz4: Downloading video info webpage
[youtube] lix0A-F6bz4: Extracting video information
[download] Destination: lix0A-F6bz4.mp4
[download] 23.9% of 8.36M at 253.36k/s ETA 00:25
ERROR: content too short (expected 8763593 bytes and served 2097856)

$ youtube-dl -f 18 http://www.youtube.com/watch?v=lix0A-F6bz4
[youtube] Setting language
[youtube] lix0A-F6bz4: Downloading video webpage
[youtube] lix0A-F6bz4: Downloading video info webpage
[youtube] lix0A-F6bz4: Extracting video information
[download] Resuming download at byte 2097856

ERROR: Did not get any data blocks
$ youtube-dl -f 18 http://www.youtube.com/watch?v=lix0A-F6bz4
[youtube] Setting language
[youtube] lix0A-F6bz4: Downloading video webpage
[youtube] lix0A-F6bz4: Downloading video info webpage
[youtube] lix0A-F6bz4: Extracting video information
[download] Resuming download at byte 2097856

ERROR: Did not get any data blocks

Here's a list of some videos this is currently occurring for
http://www.youtube.com/watch?v=PdoXMXFdZxM
http://www.youtube.com/watch?v=ZZq1g35EV6g
http://www.youtube.com/watch?v=98x4IwjEaHM
http://www.youtube.com/watch?v=SjJCI01VtVM
https://www.youtube.com/watch?v=u6c_wz9qvYA

[phihag]

Both errors mean that youtube had some kind of internal error - that should never happen according to the HTTP spec. In fact, a behavior like this is probably what happens when google's networked filesystem gives out - if you can't get a data block in the middle of serving a file, you can just reset hard, since the headers (and maybe even previous data blocks) have already been sent. Personally, I haven't experienced the issue so far.

[ghost]

Thanks phihag

When you say do a "reset hard" are you talking about my box or google's servers?

I've done a hard reset (rebooted my own box) but am still experiencing the same issue. I tried the popular front-ends http://offliberty.com/ and www.youtube-mp3.org/ and they were able to download the videos I was having trouble downloading. Note that these sites cache videos, but I tried a few obscure ones to make sure I was request a non-cached video that went through the 1) download video 2) transcode to mp3 process. I tried downloading these from boxes in oregon and california and still encountered the same problem.

I'm going to try to download from other locations like in asia and europe.

Were you able to download these files? What location are you at?

[phihag]

No, with hard reset, I meant a hard reset (i.e. just close) of the connection, not of any machine, and obviously on google's side.

I can download all those videos just fine, from 3 locations in Germany (of course, with the usual GEMA-related exceptions) and two in the US (including AWS_us-east1).

[ghost]

I can download these just fine on AWS-us-east1, no need to confirm. It seems to be an issue affecting the west coast servers.

Also - It seems like all those videos I listed are working just fine on oregon (us-west2) with exception to http://www.youtube.com/watch?v=PdoXMXFdZxM, so you can use that as a test case on oregon if you want.

Thanks for your help, I appreciate it. You da man!

EDIT: Nevermind, http://www.youtube.com/watch?v=PdoXMXFdZxM can be downloaded from us-west2 now!

[phihag]

Ok, that definitely is a problem on google's side. Most likely, they use DNS or anycast so that you always get the closest servers, and something is broken in that geographic location.

[phihag]

One more data point supporting that: From my machine in Los Angeles, I get the same errors as well, although not reproducible - I'm assuming google is already fixing this as we speak.

[ghost]

Yeah, thanks for explaining the HTTP spec and the reasons behind not getting a block while transferring data. I was just surprised it took them so long to start fixing it because It appears to have begun about 42 hours ago.

"Dream of Californication"

[ledlamp]

For anyone who has this issue on a particular video when downloading a list of videos, you want to use the -i option so youtube-dl will skip it instead of quitting.