Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--save-state - how to restart existing stream? #200

Open
jonathanbgardner opened this issue Jul 14, 2024 · 2 comments
Open

--save-state - how to restart existing stream? #200

jonathanbgardner opened this issue Jul 14, 2024 · 2 comments

Comments

@jonathanbgardner
Copy link

The README file includes reference to a --save-state flag you can include in a command line prompt that saves a portion of an already-started live stream download, but there is no reference made as to how to restart a download of a live stream after manually stopping it.

Is there a mechanism for doing so? I'm not very familiar with Go, but I couldn't find anything specifically supporting this in player_response.go.

If so, can you add it to the README file? If not, can we get support for this?

Use Case: A video editor is downloading a video from a live stream to cut into short-form clips for YT Shorts, TikTok, etc. They need to start cutting up the part they have downloaded to create YT Shorts or other short-form video from the longer video, but the live stream is still going. They need to manually cancel the stream download to mux the file, but they want to continue downloading the stream from where they started after muxing the existing files to avoid redundancy and overlap between two download files.

@Kethsar
Copy link
Owner

Kethsar commented Jul 14, 2024

That is currently not supported. It was meant to work that way, but I forgot to test manually stopping a stream when it was caught up after implementing it. The current logic just automatically starts the muxing if your download is caught up. I do want to fix this at some point.
You might be able to force it by killing the process, running the ffmpeg command manually, and re-running the yta command. On Windows you could use the task manager to kill the process, I think.

@Kethsar
Copy link
Owner

Kethsar commented Jul 19, 2024

Well after testing it seems manually stopping the stream does not actually automatically start muxing if it's caught up, and does go through the set of questions if you don't have flags set specifically to bypass them. As long as the stream has not ended, that is.
That means if you stop the stream and then answer "no" to the first two questions but "yes" to saving state, you should be able to follow the above steps without needing to hard kill the process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants