Fixed insane wait times

[DzenanJupic]

Closes #37

[cjburkey01]

Does this fix it locally for you? I'm having trouble getting it working.

[ccgauche]

I'm the author of this fix and it does work! I use it in my app called: YTerMusic (https://github.com/ccgauche/ytermusic) which works well.

[ccgauche]

@DzenanJupic Does it work (I fixed the CI issue that happened for no reason) ?

[DzenanJupic]

I'll try it out in a second, I'll first try to get #49 in, to see what's going on.
The reason the CI fails is that it forbids any clippy warnings. Don't worry about the remaining failures, I'll fix them.

[DzenanJupic]

Just tested it, it's absolutely amazing! Thanks a lot, @ccgauche.
With these changes, a 45 min video is downloaded in a few seconds for me.

[ccgauche]

@DzenanJupic May you merge?

[cjburkey01]

Using both your pull request (Discursif@6b676ca) and the "fixed" branch on this repo (f118c6b), this minimum example from the readme downloads an empty video file almost instantly:

#[tokio::main]
async fn main() {
    let url = "https://www.youtube.com/watch?v=Edx9D2yaOGs&ab_channel=CollegeHumor";
    println!("downloaded video to {:?}", rustube::download_best_quality(&url).await.unwrap());
}

Here's how I added the dependency as a sanity check:

[dependencies]
rustube = { git = "https://github.com/DzenanJupic/rustube", branch = "fix-warnings-and-rebase-master" }
tokio = { version = "1.12.0", features = ["rt-multi-thread"] }

[DzenanJupic]

I'll check that, thanks for the notice.

[cjburkey01]

I'll check that, thanks for the notice.

I'll also look around possibly tonight but I don't really understand how it works lol 🙃

[ccgauche]

The fix has been tested on a very very large amount of musics (since it was made for my music app) but wasn't tested at all on videos. Maybe using the old system as a fallback could be a good idea while we find out what causes the issue (probably related to the file size of videos since music is a lot smaller). The pytube fix is a little big longer with more things and checks so maybe they are here to fix this issue. Didn't have the time to test. In my tests on music they changed nothing so I removed them to better fit my use case and reduce the fix size.

[matejrisek]

Unfortunately some streams have content length set as zero. One of them being the highest quality stream of the example video. This leads to zero bytes being returned by the server.

[ccgauche]

I'll check on that but I don't know if there is a possible fix at least better than defaulting to old slow system...

[matejrisek]

I'm pretty sure this is not idiomatic code (this basically being the first lines of Rust I've written outside of tutorials) - but here we go - we should probably fall back to not using the Range if the content length is zero.

Suggested change

	let k = k.header("Range", format!("bytes=0-{content_length}"));
	let k = if content_length > 0 {
	k.header("Range", format!("bytes=0-{content_length}"))
	} else {
	k
	};