Add feature --live-from

[keredau]

Added support for the --live-from option.

This option allows users to specify that they want to start capturing from one of the following:

• Now
• A time in the past: e.g. 25 minutes ago
• A time in the future: e.g. Wait 30 minutes then start capturing.

---

Usage:

	--live-from [DURATION] or [NOW]
		Starts the download from the specified time duration string.
		Can be a negative or positive duration or 'now'.
		Supports Days (d), Hours (h), Minutes (m) and Seconds (s).
		Examples: * '--live-from -1h10m' will seek backwards 1 hour and 10 minutes and then 
		            start downloading from that time.
		          * '--live-from 45m30s' will wait 45 minutes and 30 seconds from now and then
		            start downloading.
		          * '--live-from now' will start recording from the current stream timestamp.

---

Features:

• Does not break resuming of a partial download.
• If a scheduled stream, checks for a negative --live-from value and exits with an error.

---

Fixes #184 and #149

[buse1453]

Thank you.
Im sorry but Im new here ,how can I download the new version and can anyone share an example of any stream?

[Kethsar]

Sorry for the late review, I was on a trip and forgot about it when I got back.

This is a good start. I tested the previous attempt before you decided to redo it, and noticed some issues in regards to the fragment counts shown while downloading. Haven't tested yet, and it doesn't look like it was fixed with the current iteration, but that's something I could work on.

I might see if I can push to your branch to help with things, since I would want it to also be able to parse [HH:][MM:]SS durations as well, which the library you are using does not do.

[keredau]

Hi,
Thanks for the feedback.

I've added support for HH:MM:SS time strings via another library. It looks like it supports days by putting an hour value >24.
Fragment counts in the Console output should be fixed in this version, i did re-work it to show the correct number. For this I also had to add another key to the state file so that it knew what the original starting FragCount was when resuming..

Overall, i'm a little unhappy with the Readme wording for the command, it's something I struggle with constantly...

Additionally I also have another branch that will add --duration support that I can submit a Pull Request for too.

[sebi-berlin]

Thank you so much for your work! Any chance on a release the following days? Next Friday the 10 Days long Tomorrowland festival 4K stream is starting, and this would come in handy. :-)

[Kethsar]

After testing real quick, I realized this doesn't actually work how I expected. It works how you wrote it to work, but now I question the point of setting it to wait a specified amount of time before starting. I would expect it to wait until the stream has gotten to that point in time, not waiting that amount of time from now.

i.e. --live-from "6:30:00" I would expect to download from the 6 hour 30 minute mark of the stream, not wait an additional 6 hours and 30 minutes. While I can see a use-case for this, it feels like it would be better labeled as "wait-for" or something similar.

[keredau]

Good point, i'll change that as you suggested. It makes much more sense.

[keredau]

Updated. --live-from +positive values will calculate from the start of the stream instead.
For a long running stream (more than 5 days) it still requires the value to be from the 'start' which i've noted does create some difficult to understand requirements. Perhaps i should always just calculate it from the 5 day limit...

For example, this stream has been live ~68 days so you'd need to use a value like --live-from 66d for it to accept it at all...

[keredau]

@buse1453

Thank you so much for your work! Any chance on a release the following days? Next Friday the 10 Days long Tomorrowland festival 4K stream is starting, and this would come in handy. :-)

Since this pull request has been accepted now, you'll be able to build a version of the application yourself from this repository.
You'll need to install GoLang from https://go.dev/ then run go install github.com/Kethsar/ytarchive@dev to build the exe.

[sebi-berlin]

My first tests were succesful, thx a lot!

This behaviour I can't understand, I wanted to start a download of a livestream that's already running, in 2 hours and 40 minutes from now on in the future, here is what it did:

ytarchive --vp9 --live-from 2h40m https://www.youtube.com/watch?v=B_dkwPx9J9Y best
ytarchive 0.4.0
2024/07/21 13:40:05 Channel: Tomorrowland
2024/07/21 13:40:05 Video Title: Tomorrowland 2024 LIVE
2024/07/21 13:40:05 Selected quality: 2160p (VP9)
2024/07/21 13:40:05 Stream started at time 2024-07-19T14:24:18+00:00
2024/07/21 13:40:05 --live-from: Starting from stream time '2h40m0s (2:40:00)' and grabbing '1d18h35m35s (42:35:35)' of content (and counting).

Is this expected behaviour?

[sebi-berlin]

Sorry, my comment was pretty dumb if I had read the whole conversation. So for my case, maybe addd it as --live-in option? :-)

[SimonEast]

When could we expect updated binaries with this new feature? Since it's in the main README I expected it to work in the latest release, but alas it does not. I guess I'll have to compile it myself in the meantime.

[Kethsar]

@SimonEast It should be in the latest release https://github.com/Kethsar/ytarchive/releases/tag/latest

[SimonEast]

Oh, I see. On the repository homepage it says that the “latest” is from Aug 2023, so that’s what I downloaded. Didn’t realise that there’s a pre-release version there that’s actually later than “latest”. Haha. 😉 Thanks for the tip.