Open revunix opened 3 days ago
Push
There are two reason this happens.
The m3u8fetch script continues to periodically poll if the streamer is offline. There have been many cases where the streamer terminates their broadcast, but both streamlink and ffmpeg captures do not detect this and keep running forever. So when the polling gets back a result saying that the streamer is offline, then any capture process is terminated with SIGINT. You can shut this behavior off by setting the following option in your twitch.yml.
noTerminateOffline: true
Sometimes the recording process just get stuck, and the streamer is still online, but the streamlink/ffmpeg process is not receiving data and the filesize of the .ts file being captured does not increase. After 3 polling loops for the m3u8fetch script, if it is observed that the filesize has not increased, then the recording process is killed with SIGINT. There is an info message that prints for this case though "recording appers to be stuck (counter=3), file size is not increasing." This behavior can not be shut off.
Thanks for the explanation! I'll test it out and see if it works as expected.
noTerminateOffline: true
Thinking about this more, the 'filesize' check was added much later than the first case where streamlink/ffmpeg don't terminate when the broadcast stops. But I think the filesize check probably also solves the same problem that the 1st check was trying to solve. I may change the default to be noTerminateOffline: true
.
Also there have been a couple of years of streamlink/ffmpeg releases since people were running into the hung-recording problems, and it may just not be a problem anymore.
This did not solve the problem.
noTerminateOffline: true
Hi,
I’ve noticed that streams are being interrupted and restarted periodically when recording with
streamdvr
. This issue does not occur when recording the same streams directly withstreamlink
or usingstreamdvr
. The interruptions seem inconsistent—sometimes the recording lasts for 4 hours, sometimes for only 1 hour, and occasionally there are no interruptions at all. I checked the logs, but there’s nothing indicating why this is happening.I'm using the following configuration:
config.yaml
Do you have any idea what might be causing this issue? Is there perhaps a difference in how
streamdvr
processes streams?Thanks for the help!