automatic push dont work after stream restarts

[mentoRisen]

Hello MistServer team,
we are encountering stability issue that is probably some bug in automatic push workflow. We are running Mist 3.10, release Free64 on ubuntu server.
Setup:
simple stream with push:// as source and tag "autorecord".
automatic push to #autorecord with target "/opt/recording/$basename/$year$month$day
$hour$minute$second$segmentCounter.ts?split=4&startunix=1783500696&m3u8=./$year$month$day$hour_$minute_basename.m3u8&maxEntries=0&noendlist=true&append=true"
OBS that push to that stream through RTMP

Use case:
we start OBS streaming, automatic push starts, everything is working as it should
we stop OBS streaming, wait few seconds, start OBS streaming (simulating problem in source stream)
mist streams comes back online correctly
automatic push do not restarts, but it stalls, stops recording and never recover - this is first problem.
we tried workaround -> script that detects stall, stop push, and let automatic mist retry start new push -> this works on Mist 3.5.1 (I have that on other server)
on Mist 3.10 workaround dont work, Mist automaticaly create new push, but it only creates one empty .ts file and empty .m3u8 and stalls no matter how many times we restarts push.
there is no way to recover automatic push after source stream restarts

If you need any more information I will be happy to assists with debugging you awesome software.
Best Regards
Lukas

[Rokamun]

Hey Lukas,

Answering here for completeness as I've also answered in the Discord, so feel free to ignore!

From reproducing it seems to be the resume functionality. Luckily we did tackle this in our current development builds: 673eeae

What's happeneing:

• MistServer receives the first stream and assigns track numbers, for example 0 for video and 1 for audio (actual numbers might change depending on metadata tracks. RTMP inputs usually see 1 and 2 as there's a AMF metadata track).
• Push output creates the master playlist and starts adding segments
• Stream push stops & restarts
• Resume support mismatches the tracks and instead of resuming on the previous ones it adds the tracks as "new" video/audio tracks (for example 2,3)
• The automatic will add 2,3 to the stream and remove 1,2 over time
  • However this is only done at the MPEG-TS level and does not work for the M3U8 playlist. That one will "stop" where tracks 1,2 stopped

I would suggest running without resume support right now, however make sure you pay attention to your playlist naming. The variables used to add $hour and $minute might change between pushes, so it will not continue on the previous playlist if a stream restart happens. You might want to lock this per day using $yday instead.

As for the fix: We are hoping to release a 3.11 this week actually, but it might be pushed to the next.

[Thulinma]

Now that 3.11 (and 3.11.1) is released - has the issue been solved?