*Something* happens that stalls the stream until next show starts

[brave salmon]

Every so often I'll see this in my logs, whatever is happening at that packet corruption is enough to throw the entire stream - it'll keep trying to send the same element again and again but I guess it can't because it's in the past so the connection just dies. I believe at the end of the show, it's able to then work itself out and restart at that new point, but it would be neat if there was a way of just continuing it faster than that.

Command I'm using to stream:
ffmpeg -rtbufsize 100M -i http://192.168.1.5:8080/stream/channels/907.m3u8 -x264-params keyint=48:min-keyint=48:scenecut=-1 -c:v h264_videotoolbox -b:v 4M -c:a aac -f flv rtmp://live.twitch.tv/app/live_xxxxxxxxx

It's the same I use with ersatz and I can generally walk away from it and let it keep itself up and when it trips it reconnects pretty quickly, although it's with music videos so maybe it's due to the program lengths there. I find with Tunarr at the moment it can run for a bunch of hours then something trips it, not too much an issue at the end of a show but a shame if it's near the beginning of something that'll run for a few hours.

[little basalt]

Does it always happen at program boundaries?

You can try adding “-fflags +igndts” to your ffmpeg command right before the input, for now

Would also be curious if the same content trips up both ETV and tunarr

[brave salmon]

No it’s happening during the episode itself, rather than boundaries. I’ll add that flag in and see if it makes a difference tomorrow. Yeah my ersatz setup is all local file stuff rather than plex so currently hard to make a comparison as it’s run so differently.

[little basalt]

Those logs are from the twitch command I guess? Give that flag a try to ignore the DTS and base it off the PTS instead

Tunarr uses this option too https://github.com/chrisbenincasa/tunarr/blob/dev/server/src/ffmpeg/builder/options/GlobalOption.ts#L52

[brave salmon]

Rad I’ll give it a shot, and yeah that’s spitting out from the ffmpeg command on my end not the server logs.

[brave salmon]

Just had a drop so I used it as an excuse to add in those flags, I put them at the start of the string i'm not sure if position makes a difference

[little basalt]

yea it should be before the input parameter

[brave salmon]

perfect, i'll keep an eye on thigns 🙂

[brave salmon]

Got a break and then it looks to be doing similar, stream goes offline but the script doesn't realize it's dead so just keeps retrying. if only there was a way for it to know to kill itself which would trigger the full reconnect