3.1.6 (2773) Playback slow to respond

ryanwilkinsonryanwilkinson Registered User
Hey Guys,

I know I don't have the newest, but I have been running into an issue with this version. I have 2 RHFB's and one laptop all running off the first RHFB's show and a DP8k with 4 universes (3 hard lines, 1 artnet).

I have been having issues where the playback of lists becomes extremely slow or unresponsive. This applies to the faders play/pause, main play/pause/skip buttons. I have my main cuelist with 21 cues in it. Randomly, it will go into this weird thing where when I hit any play button or skip fwd/back, the actual output will not change, nor the status of the cuelist. But the play button will do the green/red LED cycle just as if it would when a cue plays. After I hit the buttons 4 or so times, it will finally play the cue. But it plays the cue that is x times ahead of the current one which is the count that I had to hit the play or skip fwd button to get it to activate. This also happens on the slave consoles. I have also had this happen on 3.1.5. I haven't been able to put my finger on any kind of a common thing to make it happen. But its happening and shouldn't be.

Thanks,
Ryan

Comments

  • cmuenchowcmuenchow Registered User, Administrator, HES Staff
    edited September 2010
    More than likely the client console and/or the client laptop is causing this periodic problem. Are you using the internal DP8K of the server Full Boar or an external DP8000? Feel free to upload your show file as well and our test team can let it sit on a desk in the lab and hit play once and a while to see if we can catch it.
  • ryanwilkinsonryanwilkinson Registered User
    edited September 2010
    I was not using the internal DP8k, had an external one. I have had this happen before on 3.1.5 as well, and it was also using my tablet wirelessly. I believe though this has happened with just the console stand alone.. Hard for me to remember. Most times I am on these sites for limited amounts of time and don't have a chance to document it. It seemed to mostly happen only while programming and needing to skip through the Main cuelist (on page 2). I have uploaded this show.. See if you come up with anything..
  • ryanwilkinsonryanwilkinson Registered User
    edited September 2010
    And it did reply back with some size error.. let me know if you didn't get it..
  • cmuenchowcmuenchow Registered User, Administrator, HES Staff
    edited September 2010
    I haven't gotten any upload notifications. What's the name of your show file? I can see if it is sitting in the ftp folder.
  • ryanwilkinsonryanwilkinson Registered User
    edited September 2010
    Weird.. It is SLS_Ontario.. One was a zip of the file in a folder.. had my name on it..

    I tried it again but just get this: ERROR: Operation Cancelled. Unknown Error- Ensure no File Exceeds 50 MB Size Limit.

    I have had this error in the past..Thought you all had fixed that..

    I put it on my idisk, link below.

    http://homepage.mac.com/ryanwilkinson/sls_rw.zip
  • cmuenchowcmuenchow Registered User, Administrator, HES Staff
    edited September 2010
    Hi Ryan,

    I am back in the office this week. It appears the link to your mobile me isn't working either. Zipped folders of show files are massive. Please do a backup of the show file so that it becomes a smaller tar.gz file which should be around 3-5mb and much easier to tote around on the web.
  • ryanwilkinsonryanwilkinson Registered User
    edited September 2010
    Fixed it.. Had a typo..

    This is an archived show file.. I just put it inside another folder because when some people have macs, it tries to unarchive the whole thing down to .tar file.. That doesn't work.. So when you send it inside another folder, it will automatically take the .zip down to the folder with the show file..

    Just have gotten used to doing that..
  • cmuenchowcmuenchow Registered User, Administrator, HES Staff
    edited September 2010
    Got it. I'll load it up and take a look.
  • cmuenchowcmuenchow Registered User, Administrator, HES Staff
    edited September 2010
    I have not been able to see this problem yet but I would start troubleshooting by disabling all the art-net universe outputs on the internal DP8K 1 on the Full Boar and setting the fixture link IP address for that DP to a static address. In fact, I would recommend right clicking and removing the logical node DP8K #1 in the network window since it is going active with nothing patched. This alone might help with the hiccups.
  • ryanwilkinsonryanwilkinson Registered User
    edited September 2010
    The Full Boar I had, I took out all the artnet, and set all addressing to static for both fixture and hognet. I didn't realize that the internal can be removed! Thats awesome.. I will try this. I am sure on larger shows this will help the board out a little more.

    Have you tried using a remote computer over wifi and playing lists with that? This situation seemed to have the most issues. But it would also cause both consoles to do this as well and they both are wired together with gigabit.

    Another random note, the ethernet switch I had was the green technology one with the smart ethernet. Do you think this could have caused anything as well? I have heard of those causing weird things..
  • edited September 2010
    The wifi wireless may be contributing to your problem. Wireless is fine for remote focusing and touching up cues pre-show, but it should not be used during a live show. Wireless is prone to causing random delays, missed GOs, and a host of other problems. If often works "well enough", but is not appropriate for a real time control system.
  • ryanwilkinsonryanwilkinson Registered User
    edited September 2010
    Oh I am definitely not using wifi while in show.. Strictly for RFU. While I understand the delays in this and missed commands ect. using WIFI.. I am not seeing why this is causing either of the wired consoles to have missed go's, yet obviously tracking them when it finally takes. These are both within an arms span along with the DP8k on the same gigabit switch.
  • ryanwilkinsonryanwilkinson Registered User
    edited September 2010
    Tomorrow through saturday is the last of this show.. I will see how it goes tomorrow.. Should this happen again, is there anything I can do to get a debug output?
  • ryanwilkinsonryanwilkinson Registered User
    edited October 2010
    Well I did run into this again on that show.. Just restarted again and it was fine.

    But now I am on another show. This time, have a RHFB no networking, and about a universe and a half of stuff. hundred CB12's, 72 dimmers, and 8 mac700's. This board was my backup. I took a video of it. I just rebooted the board and it goes back to working properly. I was just showing my ME some stuff on it, and it happened. No idea of any common keystrokes once again.

    This console was literally upgraded to 3.1.7 just moments before this happened.. So its still around. And I showed the processes window showing everything is running.

    Here is the video zipped:
    https://files.me.com/ryanwilkinson/cvbgp1
  • cmuenchowcmuenchow Registered User, Administrator, HES Staff
    edited October 2010
    So right now DP8K net num 3 doesn't have any artnet enabled and DP8K net num 1 is idle when you load the show?

    Just wanted to check this because the show file from Sept 15 has an active DP8K net num 1 and some artnet settings that could potentially cause this kind of DP playback nasty behavior.

    What switch/router are you using?

    Even with that said Mike and I are in the lab trying to reproduce this with the show file you sent us in September and we're not having much luck.
  • ryanwilkinsonryanwilkinson Registered User
    edited October 2010
    The last show of the SLS gig I did I had disabled the internal DP8k net #1. I only had 3 going which was an external DP8k. I did have a universe of artnet going out to a catalyst. I believe I was using a dlink switch, no router.. It was a 8 port gigabit but it did have the green ethernet which I have heard can cause some issues.

    Basically with the other show I had, I would put the same show file on the other desk and it wouldn't work.. The conclusion I most recently came up with is that my main RHFB was good and my backup board had a hardware issue. Not sure if the disk got corrupted. I asked the shop console to do a full image on it. Next time I have it out I will check it again.

    Last night I had an issue with the good one from that show however on another new gig I am doing. It was 3.1.7. Started a fresh show and patched everything in. Only had that board in standalone, 2 universes. Plugged DMX out of the console into some MA opto's and out to my rig. Had 10 mac 3's, 48 dimmers, 9 mac 700's, 6 mac 2k wash, 8 atomics. I just had started to flash through the rig on the ground before it went up. When I grabbed a light and activated anything in the programmer such as highlight, lamp control, pan, tilt - it took roughly 30 seconds to reflect any change on the fixtures. This was happening on both universes of the console. I figured this was not bad cables. Also not the optos fault. I looked at the opto light, and the data light would bling at maybe 3hz, super slow. I could also look at the DMX window and the changes were delayed in there as well, so I knew it was something software wise.. After getting a little concerned, I tried changing the DMX refresh rate, and no change. Next thing I tried was removing all the default artnet universe output mappings. Bam, instantly better.

    If I had to speculate, there is an issue with artnet. I didn't have any link on the port since I had nothing plugged into it. Just guessing, but I feel like there is some error where something isn't realizing there is a link present and its trying to send out something thats impossible causing errors or something.

    If you need me to send you this show file I can..

    But I feel like this is all tied in. Something hardware wise with the RHFB is just not happy since I have been consistently having problems with these.
Sign In or Register to comment.