all 4 comments

[–]JasonCarswell 2 insightful - 1 fun2 insightful - 0 fun3 insightful - 1 fun -  (3 children)

The download never works for me on Grid.

[–]x0x7[S] 2 insightful - 1 fun2 insightful - 0 fun3 insightful - 1 fun -  (2 children)

I looked into it and I see a problem on brave (probably other chromes). I'm an FF user so I must have missed the bug. It probably has something to do with the way I'm doing http 206.

[–]JasonCarswell 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (1 child)

I use Brave. I thought I'd stumbled on a solution, but no. I thought I needed to jump start it and play it, for some reason that works with other sites with download issues. I even inspected the code, isolated the video to play alone in a tab just fine, but for some reason I just can't download it.

On the plus side, YouTube-DLG works!

Best option for all sites with videos, for individual videos, playlists, channels, etc:

DL = Download. YouTube-DL works via command line.

G = GUI, aka Graphic User Interface. Gives the code an interface window that's easy to use.

There are features I would love for them to add, including a browser addon, and it could be ergonomically improved. It's open-source so maybe in time.

[–]x0x7[S] 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (0 children)

I know why it does it. It's because I implemented http 206 the way the w3c says to instead of the common practice (or at least they way the w3c says I should be allowed to). Firefox is able to download from it so it shows that at least one browser is able to understand what the headers mean. And chrome browsers will play it so they clearly understand the concept of partial response. But when they download they play difficult. I wish browsers would send a request header that they are downloading it. I don't think they do because they worry people would block downloads but I would use it to do a non-partial content download.

Here's how it works if you want to know. The browser sends a request for content, with pretty normal headers. I can respond with 206 instead of 200. I then can add a header range:0-450/10000 and just send bytes 0 to 450. Usually it involves bigger numbers. Then the browser knows we are talking the 206 language. Next it will send another request when it needs it (with some lead time) but this time it will tell me what ranges it wants explicitly. It will likely say range: 451- , and that means give me any bits you are will to get from 451 to the end. And I'll respond range:451-901/10000.

It saves bandwidth, actually reduces buffering issues because I'm not over serving one client while another needs bits now. It reduces the number of open connections on the server. It's great. The only hangup is that chrome browsers refuse to understand it only for downloads even though clearly they know what 206 is and use it everyday in the player.