New post
0

Live Video - HLS stream - Network outage resilience

Avatar
Robin Carlisle
None
Follow

Hi, I am using BrightAuthor on windows to push a presentation over the local network to a BrightSign XT1144 player.  

My presentation contains a "Live Video" and I put my HLS stream into the URL field.

This works well and plays the stream fine.   However, when I stop the stream at the server end (by removing the m3u8 and the ts files) and then restart the stream - the playback is not resumed at all.  It just hangs forever.

Also, if I disrupt the network by unplugging the ethernet cable from the player and then reconnect the player - the player also does not resume the stream.

Is there anything I can do to make it more resilient? 

Thanks and hope you can help,

Rob

Date Votes

5 comments

  • 0
    Avatar
    Ken Campbell

    It is possible to make things more robust on the Brighsign when operating as a streaming/HLS client; catch and respond to network outages (local link and upstream), dropouts, restarts, etc. I had to write something for the Venice Biennale years ago that ran unattended for several months. I did everything using a state machine and event handlers, listening to and taking action on roVideoPlayer event message relating to playback and streaming states:

    roVideoEvent, roAudioEvent - Documentation - BrightSign Documentation (atlassian.net)

    Also listening to and acting on a bunch of different network-level events:

    Networking Objects - Documentation - BrightSign Documentation (atlassian.net)

    For example, listening for roNetworkAttached and roNetoworkDetached events to change state and re-establish a connection to the streaming server as required.

    I remembering the code getting quite large in order to effectively deal with all the things that could go wrong.  Comparing hashes of the .m3u8 file to determine if it was stale was something I ended up using to help with server restarts, if I’m remembering things correctly.

     

    Ken

     

  • 0
    Avatar
    Robin Carlisle

    thanks for the tips and links!   I will get on to that.  Lots to learn.

  • 0
    Avatar
    Ken Campbell

    I also used the roUrlTransfer object, triggered by roTimer events, to make requests to the streaming sever to check its health every minute. I use timers in nearly every script of any complexity to handle system state checks, timeouts, etc.

    We used a 3rd party hosted Wowza streaming server on the back end.

    I’m not sure of your application, but you may want to consider having locally cached content that your player can switch to during stream outages.

    Ken

  • 0
    Avatar
    Robin Carlisle

    That's a great idea to have locally cached content should the stream fail.    We use our own AWS cloudfront streaming server, so will also come up with some checks to check its alive and well.  Thanks again!

  • 0
    Avatar
    Ken Campbell

    You’re welcome. If you get into the weeds, let me know, I may have some code snippets that could help. I had to write a multi-level m3u8 parser on that project using regular expressions (ie. roRegEx) which was not terribly elegant or pretty looking code… but it worked solidly.

    Switching between cached content and the stream can be implemented by catching stream end events generated by roVideoplayer. Then while you’re playing cached content, use roUrlTransfer on a repeating interval timer to check for the m3u8 and startup stream playback when it’s back. There may be more elegant ways to approach this problem, such as having a monitoring agent on the server that the Brightsign could make REST requests to or open a command back-channel to)  but it worked without issue for several months with no reboots! 

    Ken

Please sign in to leave a comment.