default live app disconnects every 7:50h

[vayvanne]

Hello,

I have pretty regular setup with fmle encoder and AMS 5.0.14 on the same windows PC.

For testing purposes I run ffmpeg like this:

ffmpeg -rtmp_live live -i rtmp://localhost/live/stream -f null -

Stream disconnects every 7h 50 s.

I do not see disconnects on fmle side and do not see anything helpful in logs.

Should not default live app support 24/7 streaming?

Tips and debug suggestions are appreciated.

[Graeme Bull]

This generally happens when a core gets rolled over. Which sounds weird.. but it's the thread running for the AMS service itself, it rolls over a particular amount of minutes in, everybody that is connected, gets disconnected and the app goes on as normal.. Not sure of a better way of explaining it

[vayvanne]

Hi Graeme Bull, thanks for reply. 7h 50m is since ffmpeg starts, not FMLE or server. I suspect it is something with ffmpeg (zeranoe windows build btw), not server or live app. It also has something to do with stream itself, because another audio only stream survives a week. It can be compatibility issue with FMLE linked to timestamps as I see the following:

Fri Jan 26 2018 17:03:46 : Error: Device Timecode not supported : The selected video device or the timecode dll provided for the device doesn't support timecode generation. Disabling Device timecode generation option.

... with the FMLE option "Embed system time as Timecode" enabled.

[vayvanne]

Changed stream to VBR and now it survives for about 12h. Looks like it is media server issue somehow related to traffic volume passed.

[Graeme Bull]

That's interesting. I think it still has to do with core rollover but your cores might be maxing out later with the change. Hard to say really but that has been my experience in the past.

[vayvanne]

If it would be core rollover issue - the encoder (which is ffmpeg now) would reconnect too, but it does not. Scope, Distribute and Rollover options are switched off by default on vhost level config.

[vayvanne]

Still no solution. Stream reading ffmpeg instances disconnects reaching to 4GB traffic limit. Publishing to the same server one - survives for about 4 weeks to reach rtmp timestamp overflow. How could I debug this disconnection issue on server side?

[Graeme Bull]

I don't know of any cases where this doesn't happen at some point. 4 weeks is a long time actually, you've done well. You'll likely have to plan for disconnections instead of trying to solve this at the media server level.

[vayvanne]

Thanks for reply. 4 weeks is when publishing to the server (pushing). When reading from the server 4GB does mean only 7-8 hours of uptime with my stream. This is substandard in my view.