Highlighted

default live app disconnects every 7:50h

Explorer ,
Jun 30, 2017

Copy link to clipboard

Copied

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.

Views

3.6K

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

default live app disconnects every 7:50h

Explorer ,
Jun 30, 2017

Copy link to clipboard

Copied

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.

Views

3.6K

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Adobe Community Professional ,
Jul 31, 2017

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Explorer ,
Jan 29, 2018

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Explorer ,
Jan 31, 2018

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Adobe Community Professional ,
Jan 31, 2018

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Explorer ,
Jan 31, 2018

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Explorer ,
Aug 09, 2018

Copy link to clipboard

Copied

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?

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Adobe Community Professional ,
Aug 13, 2018

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
vayvanne LATEST
Explorer ,
Aug 13, 2018

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...