Options
Related

Artnet Latency/Artnet Drop Out

Have been working in previz for a couple days and noticed a stutter or hesitation at the execution of some cues. I thought it was probably just the previz suite, but after a few hours of troubleshooting it seems to be that artnet is dropping out for a fraction of a second on a select set of cues with and without command line macros, but it seems the trigger of a macro makes it worse.

Setup....

FB4 b540, internal DP to windows 8 computer running ArtNetominator (Artnet monitor software) which can be found here for free... www.lightjams.com/artnetominator/

And a H4PC b540, with internal DP to the same windows 8 computer running the same software.

Both desks were configured @ 10.0.0.101 for Artnet out, non broadcast, to the windows 8 client on 10.0.0.102 which was running the artnet sniffer.

Both the FB4 and the H4PC showed the same exact results of the Artnet Dropout on the same show file.

The show file can be found here... dl.dropboxusercontent.com/u/85195138/Share/Test_bck.hog3.shw



Here are a few screenshots.

On the left is the artnet sniffer and at the bottom of that is a graph of a monitored artnet channel.

On the right of the screenshots is windows task manager with the network graph up.



The first screen is from running list 6 on master 2. Going from cue 1 thru 3 will result dropouts at the execution of each cue. Cue 3 to 4 will not show a dropout and it will be a smooth fade. Going from cue 4 to 1 will again create a dropout. These can be seen on the graph in the artnet sniffer, as well as in the network graph as a valley.

dl.dropboxusercontent.com/u/85195138/Share/L6_Q4-1LoopLag.jpg


The next screen is the results from running cue 6-7 from list 7 on master 5. Cue 7 has a command line macro that runs list 6 Cue 4. Running from 6-7 you will see the dropout as the macro is triggered.


dl.dropboxusercontent.com/u/85195138/Share/L7_Q6-7Lag.jpg




The next screen is to demonstrate that if I make a copy of List 7 and remove the macro at cue 4, there will be almost no dropout at all.

The following is of List 8 on master 6, which is a copy of list 7 with the macro removed. Going from cue 6-7 on this list does not seem to create a network dropout.

dl.dropboxusercontent.com/u/85195138/Share/L8_Q6-7_NoLag.jpg




I looked through the cue contents of each cue that was causing the dropouts and could not find anything weird or outa place that might cause this. I also tested the same show file on two desks and saw the same results. I'm curious if this is only an artnet thing and if I will see the same thing on raw dmx outa the internal DP's. I did not get the chance to test this on an external DP, I wonder if it would show the same results.

I have included links to everything needed to duplicate the results. Please let me know if anyone can reproduce this and if there is a solution, as it has put a halt on me finishing this previz project.

Edit...

I forgot to mention two things...

One, I wanted to rule out show file coruption, so I created a new show and merged this into it. Same results.
Two, if you look closely on both the raw dmx screen within H4 and the output or levels window you will see a hesitation for the parameters to start their fade. I believe this hesitation has something to do with the network dropout I am seeing.

Thanks

JB
  • 0
    So I think I found what was causing the hickup or network dropout... Which actually doesn't look at all like it has to do with artnet or network related. It looks more like the H4 OS is stalling durring a memory or SSD read attempt..

    In the original show file, on list 6 master 2, I had set up a base cue (Cue 1) that was referencing multiple palettes, some of these palettes were standalone and a few of these palettes were referencing other palettes. Nothing in the base cue (Cue 1) on list 6 was direct, the entire cue was composed of data that lived somewhere else.

    So... this morning I copied cue 1 from list 6 in the programmer and retouched all values on all fixtures to remove the association to any palette and then re recorded to cue 1 list 6 over writing the cue. It fixed everything....

    Here's my oppinion on what might be happening...

    With too many palettes (Or code links) being referenced at once, it seems to stall the H4OS until it finished finding and reading all the data tucked away in the memory to execute the raw data needed to run the actual cue. By removing any reference to palettes, the read path for the OS is much more direct to get to the data needed, so it does not stall.

    Any chance someone from HES wants to comment?
  • 0
    Ok, just a hair bit more info.

    It seems that the hickup may be tied to reference palettes.

    The original base cue that posed the biggest issue was recorded from a reference palette that was recorded from a good handfull of standalone palettes. Other than making that base cue raw values, which fixed the issue.. I found that removing the reference palette and recording the base cue from only that handfull of standalone palettes reduced the hickup to an acceptable limit. Once I re recorded the same base cue with the reference palette, the hickup, or system stall came back again.

    This is unfortunate IMHO, since the beauty of the Hog is the ability to organize anything and everything through the use of the palettes.

    Edit... Just had the opportunity to speak with a fellow programmer in the UK and by using the same show file he was able to duplicate the results by using a reference palette on an H4. So it apears not to be hardware related as it shows up on an I7 H4PC an H4 and a FB4.

    JB
  • 0
    Jeff

    Thanks for the information!
    I was able to recreate this problem with your show file on a singe FB going directly into my computer running DMX workshop.
    Like you said coping the each cue to another list and replacing the palettes with hard values does appear to solve this problem.

    I have let to recreate this with a new show so I have a few questions:
    1. Was this show created new on 1.2.0 b540?
    2. Are you seeing the Artnet drop out on the Viz program or just the artnet sniffer?
  • 0
    1. Yes it was created with b540.

    2. I am seeing the Artnet dropout on windows task manager when viewing the ethernet graph, I am also seeing it within the PreViz both in the DMX display graph and seeing it with the lights in the 3d environment as a hesitation after cue execution. Also, I am seeing it on a swisson that is measuring DMX values from the back of the board. And last but not least, I am seeing it on any artnet sniffer.

    I don't think it is limited to Console output. I am also seeing a delay of all processes on the console until after the hesitation.

    Let me see if I can recreate it on a new show file.

    JB
  • 0
    I just created a new show and attempted to copy the same style of programming with different fixtures. I also made several layers of reference palettes and I am unable to recreate the hickup or dropout.

    Strange..

    Is this a one off gremlin that has burried itself in my showfile? Remember, I created a new show and merged trying to clean it up.

    JB
  • 0
    Thanks for the extra information.
    I will continue to look into this.

    Can you please give me this full history of this showfile?
    Do you have a copy of the showfile before the merge?
  • 0
    I don't think I have the original showfile and if I did, I would have no way of confirming it was the original before the merge. I merged, trying to solve the dropout, so the original was plagued as well.

    Something that just came to my mind is that, the show file you have versus the one I just created trying to recreate the dropout, has a ton of fixture info for the 4 seperate band positions, that I did not recreate with the last new show. The original file has 4 standalone position palettes. Each palette labled, "Singer, Drums, Keyboard and Guitar" has almost every fixture in the patch focused on that particular band member. Then I selected a set of front and back fixtures and recorded two reference palettes, soft backs and soft keys from the band member position palettes. Then used the two reference palettes just mentioned in another reference palette called "base". In the show file I just recreated to test, I did not go to that extreme of setting 4 positions for 60+ fixtures. All I did was throw some random parameters together and layer some reference palettes into a cue trying to duplicate the problem stemming from what I thought was simply tied to reference palettes alone...

    Thanks
  • 0
    Thanks Jeff

    I have logged a bug for this with your show attached.
    Once I know more I will let you know.

www.etcconnect.com