0

Sum User Variables?

Greetings,

 

I'm working on a video wall project that allows the user to change the content based on Live Media playlists.  In the middle of playlist, there is a section for videos to play.  The videos will always be different lengths from each other, so I am using UDP commands to send a message back to the master player when each one completes.  This message is being assigned to a variable specified in the message  ('player01Complete:1, player02Complete:1, etc.)

I was thinking that I would check on each message if all of the player Complete variables summed together = Number of players in the group, would mean that each player had finished, and we could move on.  This is proving to be much more difficult than it should be.

Does anyone have any ideas?  It seems like such an arbitrary limit to not be able to add variables together outside of a custom script.  Is there something I am missing?

I have also tried Setting a variable to $$var1$$+$$var2$$, this results in a string like: '0+1'.  Darn.

 

Thanks for any help!

 

 

16 comments

  • 1
    Avatar
    ^UD\_$

    You could use a User Variable, call it say Sum. Initialize to 0 at startup, and everywhere else when needed.

    Use conditional target in the UDP event, with a condition like:

    If player01Complete Equals 1 -> Command Increment Sum.

    That would increment Sum from 0 to 1.

     

    Place more conditions as needed for all screens.

     

    You'll need another condition to detect whether Sum has reached the number of players.

     

    Can't you simply play the longest video on the master?

    Author so shorter videos don't loop, and instead go to black at media end.

    They would wait on black, until the master starts over.

     

    Can you share a link to your presentations, so we can get a better understanding of what is it you are trying to do?

  • 0
    Avatar
    David Gaither

    Thanks for the comment!  I'm currently doing something like that, but have run into a few snags.  Working around these snags has proven to be rather time consuming, which drove me to post here in hopes of finding some enlightenment.

     

    As stated in the original post, the customer will be changing the videos by updating the playlist on BSN.   The videos are currently being authored to end on a trailer card, and the Video Play File is holding the last frame at the end of the video.  This allows each video to play out and hold on that trailer card without showing a black screen. The logic is intended to prevent the customer being restricted to fixed length videos.

     

    I am not comfortable posting the presentation as it incorporates some customer information, but I am happy to post screen shots!  

    1. Here is a shot of the Video Play File, and I am using the Media End to send the UDP Message with Value


    2. Here is a shot of the UDP Input Event on the Master player


    3. Here is the Advanced tab of that same UDP Input, along with the conditional Targets...


    4. Here are the contents of the first 6 conditional targets...


    5. And here is are the contents of the final check step, which is the count being >= # of players in the video wall.  Basically, sending the step to move on.

     

    It looks like it should work on paper, but even though the variables increase, the trigger at the end doesn't seem to fire when the count matches the number of players.

     

    Thanks for any help!

     

     

  • 1
    Avatar
  • 0
    Avatar
    David Gaither

    Thanks Shaun!  I was searching for something exactly like that, but came up empty.  I appreciate it!  I'm going to give it a shot and will report back tomorrow when I'm back at the office to test.

  • 1
    Avatar
    Bright Scripters

    Hi David,

    For debugging this, I would create a dev zone, and place a Live Text state, that shows the value of tempCount.

    Once everything works, the dev zone can be removed.

    tempCount should be reset to 0 only when the master starts playing.

    Not sure what is the purpose of allPlayersComplete. It  seems like it is a copy of tempCount. It should still work though.

    Once a player complete is detected, you need to reset its value to 0. Otherwise, it would cause tempCount to increment on the next event too.

    Conditional Targets are a little tricky. Only the first condition that's met gets executed, so there is no event that gets the opportunity to check your last condition.

     

    I think that you need to check the value of allPlayersComplete elsewhere. Try checking the allPlayersComplete in a timer, set to 0.1 sec like shown below. Instead of remaining in current state, you'd need to transition to a different state. The reseting of tempCount would need to be done somewhere else.

     

  • 0
    Avatar
    David Gaither

    No go, the plugin doesn't look like it is working.  I'm trying to enable debugging to determine why.   I did see the post on the link you provided regarding the missing parenthesis, and have added them where needed on lines 109 and 110, so I don't think it is that.

    I have configured a 'heartbeat' to evaluate the variables and sum the temp counter every 3 seconds.  On my debug screen, I don't see the temp counter advancing as the players complete as they should be.

     

    Here is the 'Heartbeat'

    And here is the new conditional block



     

     

  • 1
    Avatar
    Bright Scripters

    Hi David,

    I thought you were very close to a good solution without the plugin.

    Have you tried the timer event?

  • 0
    Avatar
    David Gaither

    @Bright Scripters,

     

    Thanks for your suggestion!  I had something like you described set up already, and the 'Heartbeat' was the timer.  I have not had luck yet making it work the way I want, but it is getting closer.  I was really hoping the script would work, as that is a easy straightforward solution.  Having the work and timers all spread out is confusing and intelligent.  Since the script didn't work and I'm not experienced enough yet to debug why, I'm making another attempt to get this method working.

     

     I'm just hoping to save myself extra work remembering when they ask for changes in a year or so, ha.

  • 1
    Avatar
    Bright Scripters

    Seems like you have the right mindset.

    Can you give me an idea about the lengths of your videos?

     

    Are those your requirements?

    Six players

    Content is served as Live Media from BSN

    Video loop

    Players play videos of various lengths

    When a video that is sorter than the longest one ends, it waits on its last frame

    Once the longest video is done, the master will command all players to start playing their videos.

  • 0
    Avatar
    David Gaither

    Sure!

    The videos are going to be varying length, based on the amount of content the user wants to put in each one.  They are currently between :34s, and 1:30.  I currently have a 'kill switch' timer set at 3:00 to manually advance the videos in the event of a failed detection.

    The requirements are close to what you inferred, they are:

    • 6 Players
    • Content is a Title card slide (Image served via Live Media playlist and Image Play File object), Video (Live Media via Video Play File), and ending with a Trailer card slide (Live Media Image via Image Play File).  This is duplicated on each of the 6 displays, driven by its own playlist.
    • The Title card is played in sync with all the displays via UDP Message, then the Video Starts playing at the same time on all players via UDP Message.  The Video Play File object holds the last frame of the video inherently.  Once all videos have reported finished, the master player then plays all the Trailer cards in sync via UDP Message.
    • I'm not set on the players reporting in when finished, it just seemed the easiest way to achieve my goal. I couldn't think of a way to dynamically determine the video lengths, and time based on that.

    Thanks!

     

     

  • 0
    Avatar
    David Gaither

    It appears that I have resolved the issue, but I am interested if you see anything I missed.

     

    I am testing on 2 company players, but feel confident that it should scale to 6 and work as expected.

     

    I added 6 variables named 'player0#Limiter', and I am using that with some conditional logic to determine whether multiple UDP messages from the same finished players should be counted.  In short, I have been running into cases where the the UDP messages from the slave players are being missed. I have 'resolved' this by adding a sleep, and a second sending from the players.  The 'limiter' variable acts as a governor as to whether or not the player complete count is incremented.

    I have added a UDP 'listener' to my event handler that listens for 'player0#<any>', and if the governor variable is low, increments the count, and turns the associated variable high.  (Increment tempCount, set player02Limiter -> 1)

    Then, I enabled the heartbeat to check the status of the complete count every 3 seconds.  If it matches, MOVE ON!

     

    So far, this is working well.  It feels overly complex and cumbersome to explain, but it gets the job done.

    I've removed most of the customer specific info from the presentation.  I'll attach an export here for review.

     

    Thanks for the help, and I appreciate any further input!

    Posted for a few days: https://drive.google.com/file/d/0ByXJgGwOHvupMWdMcG5SV0N5aGc/view?usp=sharing

  • 1
    Avatar
    Brandon

    Late to the party, and if it ain't broke definitely don't try to fix it but, a variation of what you're doing will give you more confidence of which player's reported in if the intent is "don't proceed until all players have checked in."

    1. Set a variable for each player, we'll say CheckinX where X is the player's number, 1, 2, 3, etc
      Be sure to set the Default value to something like -
    2. Set another variable for the combined player status, we'll say CheckinStatus
    3. Have each player send a UDP message to set its corresponding variable.  If you have 26 or fewer players, using a letter as the variable will make it easier to monitor (keep reading).  So Player1 sends
      Checkin1 : A
      Player2 sends Checkin2 : B
      Player3 sends CheckIn3 : C, etc.
    4. On the UDP Input handler for <any>, select the variable based on the input
    5. and on the UDP Input event or the Event Handler (if you use the Event Handler, make sure the UDP Input event transitions back to the Event Handler so it gets re-executed on each input event),
      Other>Set Variable [CheckinStatus] $$Checkin1$$$$Checkin2$$$$Checkin3$$ (...etc)
    6. In your check whether to proceed, compare the value of CheckinStatus to your value where all players have checked in, so for players 1-3 setting values ABC, you'd do a Conditional Target looking for
      [CheckinStatus] Equals ABC

    This will let you see which players have checked in just by checking CheckinStatus
    It'll start at ---
    If only players A and C checked in, it would be A-C
    If only player B checked in, it would be -B-

     

  • 1
    Avatar
    Bright Scripters

    I like Brandon's ABC status idea.

    Regardless of the algorithm's details, it seems to me that a good quality check, would be to load the exact same video on all 6 players, and make sure that no UDP message is missed.

    There is a chance that as one UDP event is being handled, a second UDP arriving at the same time, would be missed.

    You may need to use handshakes between the players. In other words, each slave would keep sending UDP messages, until the master acknowledges the message arrival.

  • 0
    Avatar
    Bright Scripters

    Hi David,

    Any luck?

  • 0
    Avatar
    David Gaither

    @Brandon

    This is exactly why I came to the forum.  I was so focused on the solution I have initially decided on, that a simple solution like that was never considered.  Thanks for the suggestion!  The version I am demonstrating next week is based on the 'solution' I posted about on Wednesday, but I will be converting to  your solution as I find it a lot simpler to explain and troubleshoot.

     

    @Bright Scripters

    Sorry for the delay!  I have been working on this and testing, but didn't want to follow up until I was sure that it was working well.  The only remaining issue I have identified is the one you pointed out -- UDP messages at the same time getting missed.

    I am working around it right now by resenting the message after a short delay, but there is no logic to it.  The final version will have some logic to it to allow the slave players to keep reporting status until it is acknowledged by the master.  Regarding the handshaking, do you have any suggestions, or pitfalls I should avoid?

     

    Thanks Everyone!

  • 0
    Avatar
    Bright Scripters

    My main suggestion is: Test well :)

    Testing with the same video on all slaves, should challenge your algorithm.

    What comes to my head right now is, that the acknowledge signal could have the same issue as the message itself, if all slaves are trying to acknowledge at the same time.

    You should pseudo randomize a delay for the repeated attempts to send the acknowledge. This way you reduce the likelihood for endless deadlock loop.

    Your 3 minutes or so "watchdog" is a good way of protecting the application from such deadlocks.

    Script on, and keep us updated :)

     

Please sign in to leave a comment.