[YouTube] Improve download speed

[Theta-Dev]

What is it?

• Bugfix (user facing)
• Feature (user facing)
• Codebase improvement (dev facing)
• Meta improvement to the project (dev facing)

Description of the changes in your PR

• YouTube throttles all requests to their streams if they dont have either a Range header or a &range=n-m URL parameter
• YouTube's throttling is triggered by HEAD requests, too. Since the downloader uses HEAD requests to determine the file size, the subsequent GET requests will be throttled, too
• I modified the downloader to use HEAD requests with a range header to determine the file size. YouTube will return a Content-Range header for these requests, e.g. (bytes 0-0/4530953) which can be parsed to get the total size.
• The improvement is most noticeable on small audio files. Songs download almost instantly now.
• Larger audio files still get throttled at the end of a download, I am not sure how to fix this.

Fixes the following issue(s)

• Fixes [YouTube] Downloads frequently slow down #8147, fixes [YouTube] Downloads slowing down then halting around 90% #8619.

APK testing

The APK can be found by going to the "Checks" tab below the title. On the left pane, click on "CI", scroll down to "artifacts" and click "app" to download the zip file which contains the debug APK of this PR.

Due diligence

• I read the contribution guidelines.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication

[opusforlife2]

Songs download almost instantly now.

I'm gonna make a shrine dedicated to you and pray there every day.

[AudricV]

Are you sure that your changes aren't breaking/changing anything for other services than YouTube?

Also, I don't really understand how can downloads be throttled with HEAD requests, since these requests only return the HTTP headers of the stream URL. Could you explain this, please?

[Theta-Dev]

Most HTTP client keep connections open to allow for faster subsequent requests. And once YouTube has recognized a download request (without Range header or params) the connection gets flagged and throttled.

Since YouTube's servers dont make a difference between HEAD and GET requests, sending a HEAD request without range headers is enough to have your download speed throttled.

To prove my point: forcing a reconnect (for example by reinstantiating the HTTP client) after the HEAD request prevents the throttling. I tried this with my rust-based YT downloader.

I dont see how this limits compatibility with other services. HTTP HEAD requests simply return all headers that would be returned on normal GET requests, so a HEAD request with range will return the headers of a partial response.
Partial responses always contain the Content-Range header which contains the total size of the file if known (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range).
If the server does not support partial responses, it will not return 206 (Partial) as a response code and the file size will be extracted from the regular Content-Length header.

I have tried it with all services and did not encounter any issues.