The only viable workaround

timeout --signal=INT --kill-after=10 --preserve-status 60 streamlink ...

https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.html

… when running from within a Python script, I meant. But yes, that is a more general solution of course!

when running from within a Python script

Then you don't need streamlink_cli

The example I gave is just a dummy example to show a workaround. It could have been written in whatever other programming language. If you're interfacing with the API, sure, you can do that, but like I wrote above, it will mean you have to re-do most of the CLI work. So I was looking for a more general solution.

Feel free to close this issue if you don't think it's necessary.

Thinking about it more, I believe there is a case for an even more general clean exit. Quitting the stream with SIGINT leaves you with possibly broken output, e.g. in the above case,

ffprobe -count_frames tmp.mkv

Runs into this error:

[matroska,webm @ 0x6f3dfc0] File ended prematurely

Because the signal may abort the download somewhere in the middle of a segment being written out.
Perhaps that is the real issue, and SIGINT should be trapped and forwarded to the function that writes the data, making it wait until a segment is completely written (eventually force-closing after a second SIGINT, or with SIGKILL).

HLS streams have an option for ending the stream gracefully at specific segments:
https://streamlink.github.io/cli.html#cmdoption-hls-duration

DASH streams currently don't have such an option. And for other non-segmented types of streams, it's not possible.

Oh, I didn't see that, thanks. In that case it could probably be added for DASH. I will look into whether I can create a PR.

And for regular SIGINT/SIGTERM behavior, it's not possible to always end cleanly/gracefully, because Streamlink's ringbuffer is unaware of its content structure, meaning when the CLI stops reading, it can be at any point, just like you've said. The various stream implementations simply write the contents to the buffer which the CLI or API consumers are reading from. Streamlink's main purpose is not recording, so if you need to fix your files with ffmpeg after recording, so be it.

I will look into whether I can create a PR.

I can have a look at this tomorrow or so. The --hls-duration CLI argument and respective session option should be deprecated in favor of a new --segment-duration argument (or so), so we don't have two separate HLS and DASH options which do the same stuff.

Not sure yet though what this will mean to --hls-start-offset. Implementing the respective logic for DASH streams might be a bit trickier, but it doesn't necessarily have to be implemented now if we also decide to rename it (and deprecate the old name).

Sure. --segment-duration however seems ambiguous to me, as I understand that to be the duration of a single segment. --stream-duration would make more sense, or --max-stream-duration. This could simply override stream.duration and set duration_limit as before in HLS.

I want to avoid --stream-duration, because as said, it's not possible for every stream type to implement this. --stream-segmented-duration should work though and it'd align with the already existing --stream-... CLI args.

These changes however won't make it into 6.0.0. That release will be out very soon and I don't want to delay it any further.

I have a local branch ready which I will submit later.

This will deprecate --hls-duration and add --stream-segmented-duration in favor of the HLS-specific one. Both HLSStreamWorker and DASHStreamWorker will support stopping the stream early when a duration has been set.

Theoretically, this could/should be implemented in the SegmentedStreamWorker base class, as it's only subclassed by these two stream implementations (and the custom UStreamTVStreamWorker implementation as well). The requirement here is that workers have to deal with segments which implement the duration attribute. I don't know though if that's a good idea, because this requirement is not specified and there's no guarantee that this always the case in custom segmented stream implementations. The design of the various stream APIs isn't ideal and lots of typing information is also missing. I've talked about that in the past a couple of times already, but making changes is really difficult. Starting anew with a clean streams implementation (ideally an async one based on httpx without threading nonsense) is also difficult and very tedious.

Then there's the issue with the related --hls-start-offset parameter. For HLS playlists, the implementation is simple, because segments are all known. In DASH manifests however, the representation.segments() method is a generator, which makes an implementation problematic and we can't figure out a start offset easily, depending on the DASH stream type. I would like to solve this in the same release, because as said, those parameters are related, and deprecating one after another in different releases is bad. I haven't had the time and motivation yet to check this.

Oof, that does not sound that easy. I've recently had my issues with a DASH stream without known durations and I can relate to this. I'm not deep into the code base but happy to test/comment on any proposed changes if that helps. Thanks for sharing your considerations!

See #5493