Desk slows down

bnjiebnjie Registered User
Hi

For me it seems to be a problem i also had in one of the first software versions, everything works, but when i use a HTP fader its like there is a fade time attached to it, like 4 or 5 seconds. also when i work in the programmer and are editing intensity, pan,tilt or what ever, it responds with a delay. It becomes very slow.
After a restart, the console responds fine again.

Brian Njie
«1

Comments

  • teericksonteerickson Registered User, HES Alumni
    edited March 2007
    Brian,

    Are you running v2.1 b1618 software on your console?
    After you restart the console, how long is it before it begins to slow down again?
    What software version was your show file created with?
    What external peripherals do you have connected (DPs, wings, ext. monitors, client consoles, etc.)?

    Thanks.
  • bnjiebnjie Registered User
    edited March 2007
    I am running v2.1 b1618 1 dp connected and 2 Elo touch screens.
    The show was created on the last software version, i updated just before i started programming a new show with the old patch setup.
    Its like after programming a whole day and everything is fine, then i come back next day and after an hour or so the console starts to slow down.

    Brian Njie
  • teericksonteerickson Registered User, HES Alumni
    edited March 2007
    Brian,

    Are you shutting down the console and the DPs at night?
    If the console ends up in this state again, I'd like to know if power cycling the DPs fixes the problem or if you have to actually restart the console.

    Thanks.
  • jabadgerjabadger Registered User
    edited March 2007
    Speaking of console slow down, I still get it after long sessions of programming (Big Sigh). And by that I mean an hour or so. The usual rebooting of the system purges it out. I'm pretty depressed that this is still the norm.

    2 Consoles (RCU, Console), 1 DP, 1 MTC, 2 Touchscreen.
  • teericksonteerickson Registered User, HES Alumni
    edited March 2007
    Jason,

    Has this improved or become worse with v2.1?
    Is everything slowing down? command line responsiveness? view recalls? output / cuelist window redraws? live control of fixtures in the programmer?

    There may be some things that we can take a look at to find out what exactly is causing the problem. If it's just general slowness, it may be resource exhaustion and we have some tools available to help us pinpoint which process is the issue. Let me know how you're seeing the slow down and I'll check with the developers here to see what we can do.

    Thanks.
  • jabadgerjabadger Registered User
    edited March 2007
    All of the shows I do on the console rarely if ever have moving lights on it. This particular attraction does for once and over the course of several hours of programming it reacts pretty similar to what I remember on one show I did in 2004 that had 3 DPs patched full. This is just 1 DP pretty full but I'm only programming fixtures patched to 1 Universe right now, haven't gotten to the other ones yet.

    As I get deeper into programming during the night (selecting, copying, effect building, editing, normal stuff) about 3 to 4 hours in the console really becomes sluggish and useless to the speed of programming that I've deemed acceptable on the console (I'm programming on the client).

    The console is stable though and hasn't crashed on me. However, at the end of the night I did what I usually do - saved and burnt a copy then did a Garbage Collect and Integrity Check. I only got as far as Garbage and it went crazy and locked up and network error and FPS something or other error. I was able to pig+open+backspace and eventually got to the Log Off. But it locked up somewhere and I needed to turn the power off. On reboot and reload I got an Array Load error during the Server Powerup. I checked the cuelist I was programming once the show loaded, looked at the list and the console deleted 200 of my cues. The last cue listed was 5 something followed by cue 0. Total barf.

    Anyhoo, should put a warning out there: If the console is behaving sluggishly DO NOT use Garbage Collect.

    To answer your specific question below, when I say slow down the things that have been burning me; Group Selecting, Pallete Selecting, Intensity Entering, Cue Recording, Clearing the programmer - Crossfading becomes studdered.


    ---a little off topic---
    This is a SMPTE show by the way. I have been pleased with the response of playback and learning. There is a bug I have found with Learn Timing enabled on a cuelist and then when you create another cuelist, sometimes the Learn Timing moves over to the newly created cuelist, I dunno though, I'll see if I can find it. Also, the main quickstep forward button doesn't always work and the main play button doesn't either during the course of creating and stepping around in cues after edits and such. Sometimes it requires double hitting to advance.


    That's all, danka!
  • Marty PostmaMarty Postma Registered User
    edited March 2007
    Jason, you say you rarely if ever have any moving lights patched in....so I take it you are using mostly Desk Channels or maybe LEDs?

    I've run into issues with too many HTP channels on a DP-2000 slowing the system down , especially if the DP has to calculate a lot of crossfades like running the FX engine.

    Adding more DPs to split/handle the load is currently the only workaround I know of for this.
  • jabadgerjabadger Registered User
    edited March 2007
    Mostly just desk channels, my shows really aren't demanding, just a lot of MSC Triggers.
  • nibornibor Registered User, Hog Beta
    edited March 2007
    This take out the trash thing has made me look like a fool many times on a show, also a warning should be posted about deleting a cue list from the cue list window,+ trash removeal the console go'd nut's and has to be powered down = you look like a Twit

    This is somthing that need fixing very soon.

    I here that Martin is sending out updated faster hardwear to all Maxxyx owners at no cost is this ever a posabilty or will this post vanish quick

    Still love the console but by now it should rule

    RD
  • teericksonteerickson Registered User, HES Alumni
    edited March 2007
    Jason,

    I'm glad to hear that things have been stable for you lately and I'm very sorry to hear that you lost show data. That's a worst case scenario for us and something I'll definitely fight to get dealt with.

    I haven't spoken with the developers yet, but I think you're probably battling one of two issues. The first would be our unlimited undo stack. Undo history information is saved until the console is logged off or a garbage collect is performed. If you're programming for hours, this can be a significant amount of data and may be slowing you down. The real fix for this would be for us to limit the undo history to an arbitrary number of undos and clean up as we go. The workaround would be to periodically log off and back on or run garbage collect. The other possibility is that you may have found a memory leak somewhere that could be affecting you.

    Are you running v2.1 software?
    When the slow down happens, does it affect responsiveness on the server?

    There are a couple of things I'd like to take a look at, but I'm going to take this offline. I'll send you an email and we can talk about how we might be able to track this down.

    Thanks.
  • teericksonteerickson Registered User, HES Alumni
    edited March 2007
    Robin,

    I haven't heard about Martin sending free hardware updates and I'm not seeing this on their website. If you can send me a link to where you're seeing this, I'd be interested in looking into it.

    Whether this is truly what they are doing or not, it won't necessarily mean that we will follow. We are constantly working to improve the performance of the console in ways that will have the greatest impact for the majority of our user base, as you can tell by the recent views improvements. If we make hardware changes to the console, we will need to sit down and find the best way to make those improvements available to existing users. This decision will be affected by a number of factors, including cost, mechanical compatibility, and customer needs. I think you're putting the cart in front of the horse here. Keep in mind that we're all happiest when our users are happy and that's what we strive for, but we do need to make feasible business decisions that allow us to continue working to improve the product.

    By the way, it looks like you may have responded to a few of the automated forum post notification emails. I wanted to let you know that it's probably best for you to email me directly if you have something you don't want to post here because the reply-to address on the notification emails isn't one that gets checked regularly.

    Thanks.
  • SBlairSBlair Registered User, HES Alumni
    edited March 2007
    "I here that Martin is sending out updated faster hardwear to all Maxxyx owners at no cost is this ever a posabilty or will this post vanish quick "

    Robin,

    I have to say I'm a bit offended by your insinuation that we censor the forums here or would delete a post just because we don't like what is said or would disagree.

    The only posts we have ever deleted here are the ones that fall into these categories:
    • Outright Spam (Viagra and Rolex Watches).
    • Duplicate posts (somone posting the same exact question in multiple forums at the same time).
    • Beta Discussion in the public areas. (Every once in a while someone makes reference to something in the public forums that belongs in the Beta forums).
    There are plenty of posts and discussions on these forums that I think most users wouldn't be surprised or offended if we did remove, but we don't. We happily will try to address any issue that a customer raises as best we can. Sure, not everyone is happy with answer, including us sometimes, but we don't shy away or hide from the difficult questions or issues as other companies do. (Feel free to cruise around Lightnetwork if you have any doubts of this).

    It's a sensitive topic because I don't want the hundreds of other people that read your comment to get the wrong idea about how we run the HES forums here.

    As Tom said, we are constantly improving the console and our software developers spent a great deal of time working directly with you on the Views alone. As we have proven there are many improvements that can be made in the software for performance that will benefit all the users, rather than just a few if we were trying to throw hardware at a problem that is better solved by properly architecting the software.
  • nibornibor Registered User, Hog Beta
    edited March 2007
    Scott, I am sorry if you feel I was a bit of a snit but after 5 years of H3
    (yes it is getting better ) I still live with the fear on a show that the console could crash this is not a nice place, last year with 10,000 attendees woundering what was going on and an LD yelling + a large production company vowing never to use me ever again this happend.
    Do not get me wroung I run all sorts of consoles and I love H3 the most
    but it is hard pitching a console on a show where production people have a bad tast already. what I was trying to say is can the console compeat
    with hardwear designed 7 years ago it is your top console it should kicking ass out there maybe a retro fit because I own oneand would love to have it requsted like my H2 were

    RD
  • teericksonteerickson Registered User, HES Alumni
    edited March 2007
    Robin,

    Changing the hardware in the console isn't going to affect how frequently it crashes.

    Changing the hardware on the console would be a *huge* undertaking. If you want hardware that can be installed into existing consoles then we would have to design a custom motherboard, which is an expensive and time consuming project.

    All of the resources that would be dedicated to designing, developing, and testing this new hardware are resources that would no longer be available to work on other development projects, including improving the stability of the console.

    You mention that you had more requests for your Wholehog 2. Keep in mind that the processor in the Wholehog 2 was less powerful than the processors in most modern cell phones and the Wholehog 3 is far ahead of that. I believe that continuing our efforts to improve performance and stability will do far more to please our users than upgrading hardware would.
  • jabadgerjabadger Registered User
    edited April 2007
    Searching through old posts I found another instance where doing a garbage collect and rebooting messed something up...

    http://forums.highend.com/showthread.php?t=2075
  • dandan Registered User, Hog Beta
    edited April 2007
    Back to the Original Thread......
    build 1618
    1 H3
    2 DP
    NO EXTERNAL MONITORS
    NO WINGS ATTACHED

    I find the programming performance of this current build absolutely dreadful. After about 1 hr or editing cues and palettes.. the console seems to glue up.

    When VIEW CUEing... and EDITing.. using UPDATE can take between 4-5seconds to take....

    So you can imagine the effect this has on programming time, when the average song has 30ish cues.
    I will try power-cycling the DP's today when it happens and see if that fixes it.
    But... as I have nothing patched on the DP's at present (fixtures in show, but I have cleared the patch).. I doubt it will do anything.
  • teericksonteerickson Registered User, HES Alumni
    edited April 2007
    Dan,

    Are you noticing that everything you're doing on the console is slowing down?
    If there are some things that are slow and some that aren't (fixture selection, updating, recalling views, etc.), that could be very useful with helping us track this down.

    Thanks.
  • dandan Registered User, Hog Beta
    edited April 2007
    Tom,

    Mainly:

    When VIEW CUEing... and EDITing.. using UPDATE can take between 4-5seconds to take....

    Dan
  • teericksonteerickson Registered User, HES Alumni
    edited April 2007
    Thanks Dan.
    I just wanted to confirm that this problem wasn't affecting everything. We'll start digging into editors here in the test lab and see what we can find. If you happen to determine that there are any contributing factors to this problem, please let us know.
  • z6p6tist6z6p6tist6 Registered User
    edited April 2007
    I'm also seeing a lot of what I would call 'general stability' and 'speed' deterioration in much the same way as Dan.

    A fair amount of (non-reproable) desktop crashes and a few console croaks, which become more severe and more frequent the longer I've been logged in.

    I'm noticing a lot of dead 'dialogue' processes building up over time. Are you seeing this as the console slows down Dan?

    PG
  • dandan Registered User, Hog Beta
    edited April 2007
    Can't tell, as the second it shows signs of slowing down I shut everything down and restart it....
    ... I will keep my eyes out for the dead processes.

    D
  • teericksonteerickson Registered User, HES Alumni
    edited April 2007
    The reports here of slowness and instability concern me greatly and I'm very interested in reproducing them. The problem here is that before I can get a bug over to our developers to actually get things fixed, I need a way that I can empirically demonstrate and reproduce the problem.

    Thank you to those of you who have provided details regarding the problems you are having.

    To those of you who have not, here is what information I need from you:

    What hardware are you running? (Hog 3 / Hog iPC, how many DP2000s, etc.)

    How are you seeing the slow down? Is it the command line, or updating data, or windows redrawing slowly, or jerky crossfades, or something else?

    Have you received any error messages or other unexplained console behaviour?

    How long has your console been running when you start to see this?

    Does it slow down over time, or does it suddenly become slow?

    Is there a way to recover from this? If you close all windows, release all playbacks, turn off autobackup, or anything else will the console return to normal operation?

    Does power cycling all of your DP2000s help performance at all?

    Does logging off and back on help performance, or do you need to fully reboot?

    What were you doing before the slow down?

    *Any* other information you can provide about your particular operating environment may be useful. Without a way for me to reproduce this and show it to our developers, we will not be able to address these complaints. I will be looking into this, but help from you will greatly increase my chances of success.

    On a side note, this should have nothing to do with dialog processes showing as not responding. I've mentioned this in a few threads here and in some private emails with some of you, but allow me to explain this separate issue.

    We use a separate process for displaying message boxes to users in some cases. There are a few reasons for this, but the main one is that we want to bring up an interface for user interaction, but we don't want to interrupt the normal operation of a process (like playback, for example) to do this. This dialog process *does*, in almost all cases, exit cleanly. Unfortunately, it does not usually clean up after itself and remove its entry from the launched processes window. This causes the launched processes window to show one or more dialogue processes as not responding, when in all actuality they finished what they were doing, exited, and are no longer using system resources. This is a cosmetic problem that is on the list to get fixed, but is a lower priority than other issues that actually affect console operation.

    I hope this clears things up.
    I look forward to hearing the details about your reports of performance and stability problems.

    Thanks in advance for all of your help.
  • z6p6tist6z6p6tist6 Registered User
    edited April 2007
    What hardware are you running? (Hog 3 / Hog iPC, how many DP2000s, etc.)

    Big Pig
    1 DP2000

    How are you seeing the slow down? Is it the command line, or updating data, or windows redrawing slowly, or jerky crossfades, or something else?

    Mostly in the responsiveness of fixtures in the programmer. I'm also still noticing a lot of lag in the appearance of dialog boxes after edit commands. (i.e. recording add'l info into an existing cue should result in an instantaneous insert/merge/replace dialog, but takes 1.5-4 seconds on any try)

    Have you received any error messages or other unexplained console behaviour?

    As noted in other bug reports

    How long has your console been running when you start to see this?

    Generally 3 hours or more

    Does it slow down over time, or does it suddenly become slow?

    Slows down over time

    Is there a way to recover from this? If you close all windows, release all playbacks, turn off autobackup, or anything else will the console return to normal operation?

    Logging off seems to help a bit.

    Does power cycling all of your DP2000s help performance at all?

    Unsure - will check later

    Does logging off and back on help performance, or do you need to fully reboot?

    Logging off generally helps, though restarting seems to improve the console health for a longer period of time.

    What were you doing before the slow down?

    Recording cues, learning timing from CD, adjusting timecode on individual cues

    *Any* other information you can provide about your particular operating environment may be useful. Without a way for me to reproduce this and show it to our developers, we will not be able to address these complaints. I will be looking into this, but help from you will greatly increase my chances of success.

    Show file e-mailed to Brad and Tom. The show has been around as a whole for two or three years, and has been regularly updated to latest builds. Cyberlights and technobeams may be from a very old library originally.

    Hope that helps some.

    PG
  • z6p6tist6z6p6tist6 Registered User
    edited April 2007
    Oh yeah.

    Thanks for the descriptions of the 'dialogue' processes. Good to know that I need not worry about them.

    PG
  • jxgriffijxgriffi Registered User, DL Beta, Hog Beta
    edited April 2007
    teerickson wrote:
    What hardware are you running? (Hog 3 / Hog iPC, how many DP2000s, etc.)
    HOG 3 with 1 DP2000, 2 Ext. Monitors
    teerickson wrote:
    How are you seeing the slow down? Is it the command line, or updating data, or windows redrawing slowly, or jerky crossfades, or something else?
    Slow down that I am seeing was more in general responses to command lines and updating data. After merging a cue, it would take up to 1-2 seconds before the data would show live on stage.
    teerickson wrote:
    Have you received any error messages or other unexplained console behaviour?
    No message at all....notice the sluggish behavior and I opened the processes to see 6-7 "dialogue process" not responding issues....along with editors and desktop not responding.
    teerickson wrote:
    How long has your console been running when you start to see this?
    Today was approximately 1 to 1 1/2 hours of programming
    teerickson wrote:
    Does it slow down over time, or does it suddenly become slow?
    Hard to say....it might be over time, but once you notice it, it's pretty drastic at that point.
    teerickson wrote:
    Is there a way to recover from this? If you close all windows, release all playbacks, turn off autobackup, or anything else will the console return to normal operation?
    I tried everything to close windows, release all playbacks, etc. The only thing I didn't try was to turn off Autobackup. I just turned off the Autobackup and I'll see if that makes any difference.
    teerickson wrote:
    Does power cycling all of your DP2000s help performance at all?
    No...seems to be purely related to the console.
    teerickson wrote:
    Does logging off and back on help performance, or do you need to fully reboot?
    No...I had to fully reboot to get back to where I was.
    teerickson wrote:
    What were you doing before the slow down?
    The first time, I was updating/creating palletes for the show. The second time I was starting to program looks when it got really bad. I was only 4 cues into the service.
    teerickson wrote:
    *Any* other information you can provide about your particular operating environment may be useful. Without a way for me to reproduce this and show it to our developers, we will not be able to address these complaints. I will be looking into this, but help from you will greatly increase my chances of success.

    On a side note, this should have nothing to do with dialog processes showing as not responding. I've mentioned this in a few threads here and in some private emails with some of you, but allow me to explain this separate issue.

    At the same time as all of this, I also started getting the "play/pause" leds acting up again and sticking on.

    If you want a showfile, let me know.

    EDIT:
    I just wanted to add...yesterday, I was programming on a different Hog running two builds behind. I programmed for a full 8 hours with absolutely NO slowdown....just an FYI.
  • rodbelampyrodbelampy Registered User
    edited April 2007
    1 - Hog 3 (v2.1.0)
    1 - DP2000

    I have been finding these problems also.

    All the symptoms are very similar. In addition to the above information I have also noticed that if the console has started to slow down it definitely seems to get worse over time. It also affects the playback of HTP faders with intensity information in them.

    For example; if you fade fast between 2 faders repeatedly for a while and you stop the console output will keep fading after you have brought both faders down. However using the flash buttons does not have any delay on it. The problem will not happen if no programming has been done before the show.

    I have also found that hard resetting the DP solves the problem.

    When the show is moved to our main console, which is an identical setup except it is running build 1216 the same problem happens.

    I hope this information helps in tracking down the problem.
  • SourceChildSourceChild Registered User
    edited April 2007
    What hardware are you running?

    H3, 1 DP, 2 19" Elotouch @ 1024x768

    or

    H3, 2 DP, 2 19", three HPCs (One running server, one running as stage editor, one next to the hog), and Laptop w Vision and/or WYSIWYG.

    How are you seeing the slow down? Is it the command line, or updating data, or windows redrawing slowly, or jerky crossfades, or something else?

    Lags on soft button touches, slow view restores, delays in Programmer/Editor updating, funky flashing of red selector in cuelist window. Moving, copying, and deleting palettes. Opening the fixture window and "edit fixtures" will just about crash the desk if I do it after more than an hour of programming. Editor Update "fade changes" delay before fading.

    Have you received any error messages or other unexplained console behaviour?

    "Server Busy..." Usually happens after about 2 hours and fast touching.

    How long has your console been running when you start to see this?

    I can turn on the desk, run one show, come back the next day, and as long as I did no editing, the desk is fine. (Many hours). Or. I turn on and within a hour "in the zone" pressing buttons like a mad man, I reach a lockup or a big lag.

    Does it slow down over time, or does it suddenly become slow?

    I can argue both points. Sometimes it seems as if I touch too fast or key in on the command line fine one minute and the next, I am thumb twiddling when I do a "1 thru 12 @ Full" or a hop between a dozen palettes.

    Is there a way to recover from this? If you close all windows, release all playbacks, turn off autobackup, or anything else will the console return to normal operation?

    My rule of thumb is that if I open the process window and I have a process "not responding" even if only for a second then I reboot.

    Does power cycling all of your DP2000s help performance at all?

    Will have to try this.

    Does logging off and back on help performance, or do you need to fully reboot?

    When it's console and DP only, I just reboot and eat gummy worms and pee why I wait. When I have 3 hpcs online, I just log the desk off and reboot and try to keep going on the pc next to me. Usually unless it was a server lock up (very rare and thank you for that), rebooting the H3 seems to work ok.

    What were you doing before the slow down?

    Opening and closing editors and switching views.

    *Any* other information you can provide....

    Apart from some of the others here, I can honestly say that this build starts out of the gate faster than the last one and seems faster overall but the last released build also proved to be lagging after a few hours (or just one when I'm "in the zone").

    This is an old show. I have been tweeking this show since the release of 1.3.8. I've got probably 100 cuelists 20 or so pages, and a few hundred palettes. I suppose it says a lot about longevity.
  • SourceChildSourceChild Registered User
    edited April 2007
    rodbelampy wrote:
    ...It also affects the playback of HTP faders with intensity information in them.

    For example; if you fade fast between 2 faders repeatedly for a while and you stop the console output will keep fading after you have brought both faders down.

    Yes, heck yeah! Sort of like a fade lag. I've noticed this on crossfading with a fader too.
    rodbelampy wrote:
    However using the flash buttons does not have any delay on it.

    Nope, flash and flash configured as Go work fine. Go off of zero also seems to work.
    rodbelampy wrote:
    The problem will not happen if no programming has been done before the show.

    Like I said in the post above, if I don't touch a palette or an editor function, the console could stay on for a week running 20 shows with no lag.
    rodbelampy wrote:
    I have also found that hard resetting the DP solves the problem.

    Wow, I really gotta try this.
  • dkayserdkayser Registered User, HES Alumni
    edited April 2007
    Wow! All of you, great information. Many, many, thanks. We have an urgent desire to understand and solve this, and without your help it would be most difficult. :) Donald
  • dbrown9353dbrown9353 Registered User
    edited April 2007
    2 - Hog 3 2.1.0 b1618
    1 - DP

    I just had a sudden slow down. Response became choppy and delayed. seemed to effect cues that were running and channels that were being called up ( up to 3 sec delay between enter and execution ) We have been programming with 1 console for 7 hrs (the second console is being used for focus. same amount of time, the programming console is the client) The delay affected both consoles. The screen of the console showed no delay but the fixtures were not responding with out delay. All perameters, All outputs. No error messages on consoles or DP. Power recycle on DP fixed problem. Show is tomorrow should I roll back software? Its just a trade show booth but it cant go black while i reset the DP.

    Dean Brown
  • dkayserdkayser Registered User, HES Alumni
    edited April 2007
    No, I would not recommend rolling back software, I am confident you will be fine for a show environment.

    I do recommend that before any show you start with a freshly loaded show file. Reasons for this are many, but basically it allows the system to recover resources. This is more true of the DP than the console since it has fewer resources to begin with.

    Tom has been working on reproducing this error, once that happens we can investigate the state of the system. Also you mentioned it was a 'sudden' slowdown, was there anything just prior to the slowdown that you recall doing?

    I hope this helps.

    Donald
  • SourceChildSourceChild Registered User
    edited April 2007
    dkayser wrote:
    ...before any show you start with a freshly loaded show file...

    Just a possibility here but I noticed that when I reloaded a show the slowdowns didn't become as apparent.

    Scenerio was normally 6 to 8 hours of programming on a show that has been sitting in the desk for months.

    I saved the show do a disk, wiped the desk of show files to clean up and after reloading just the current file, it worked better.

    Now, 6 to 8 hours and not as much slowdown that I am aware of (at least in the past week).
  • dbrown9353dbrown9353 Registered User
    edited April 2007
    Thanks Donald,

    The main console was just running Q stacks. 2 stacks 1 with 51 Q's 20 macs Split fade times running as a loop. The second fader 28 Q's, 14 LED's also a loop.

    I had just finished adding 2 LED's in the fixture sched and patched them.

    We were in the "delay" state for about 15-20 min before I reset the DP. It seemed like a DMX refresh issue, that is why I went for the DP reset.

    I plan to run a separate DP with second console as a B/U and do a hard DMX transfer if I have a problem during the show.

    I'll let you know if it happens again.

    Dean Brown
  • Jan OpsethJan Opseth Registered User
    edited May 2007
    Hi There,

    Im VERY interested to hear what you have discovered regarding adding an new DP, beacuse we are seeing some really hard slowdown here when programing (editing) but not att all with playbacks.

    Running one heavely loaded DP, I suspect it is that that fails.

    I have one more here that was supposed to be my back system, but if someone can confirm that it REALLY helps to move some stuff from the 1st one too the 2nd, I´will do that.

    :angryfire:

    jan opseth
    dbrown9353 wrote:
    Thanks Donald,

    The main console was just running Q stacks. 2 stacks 1 with 51 Q's 20 macs Split fade times running as a loop. The second fader 28 Q's, 14 LED's also a loop.

    I had just finished adding 2 LED's in the fixture sched and patched them.

    We were in the "delay" state for about 15-20 min before I reset the DP. It seemed like a DMX refresh issue, that is why I went for the DP reset.

    I plan to run a separate DP with second console as a B/U and do a hard DMX transfer if I have a problem during the show.

    I'll let you know if it happens again.

    Dean Brown
  • dandan Registered User, Hog Beta
    edited May 2007
    Jan,

    I always split my DMX load across all available DP's (Including the Spare).. and have never loaded a DP at more than 75%... this has always worked fine for me and given great playback response.
    I would advise against patching the spare DP as a backup, as when I tried this (admittedly on V1.2) when one DP was glitching, I was able to record cues that only applied to the light patched to one of the DP's and would not playback on the "spare"...

    ... This slow-down has occured to me with the latest software when I have had no DP's connected, so I am sure that its not a DP issue.... (I normally do all my blind pre-programming without the DP's, as its faster).

    The way to get the best performance out of the Hog-3 in a playback situation is the "Kylie Method"...

    1)Back-Up Your Show.
    2)Garbage Collect (and with this new software... wait a bit once its done or it will crash)
    3)Check Integrity (wait a bit afterwards.. for the same reason as 2)
    4)Shutdown the Console
    5)Pull the mains out of the back of the DP's
    6)Count to 10
    7)Power up the console
    8)Load the Show
    9)Once the console has loaded the show and all of its toolbars.... power up the DP's
    10)Wait until the DP's have loaded the show and are both Online.
    11)Go to the 1st Show Page
    12)Hit GO a couple of times on every cuelist
    13)Pig+Release
    13)Goto the 2nd Show Page... & repeat 11 & 12 until you have Loaded all the used Cuelists into the DP's
    14)Run the Show

    I get all my Operators to do this during changeover on every tour we send out (and have done for the past 3 years) and it makes for a super-fast playback console.

    I hope this helps.....

    D
  • jabadgerjabadger Registered User
    edited May 2007
    Dan,

    Why is that called the Kylie Method? :-)
  • Jan OpsethJan Opseth Registered User
    edited May 2007
    Dan,

    Thanks for the info, but as I stated the playback is not the problem here, the editing IS.

    And the second DP was indended for a completely seperate HogPC system that has the same show loaded, for backup purpose.

    dan wrote:
    Jan,

    I always split my DMX load across all available DP's (Including the Spare).. and have never loaded a DP at more than 75%... this has always worked fine for me and given great playback response.
    I would advise against patching the spare DP as a backup, as when I tried this (admittedly on V1.2) when one DP was glitching, I was able to record cues that only applied to the light patched to one of the DP's and would not playback on the "spare"...

    ... This slow-down has occured to me with the latest software when I have had no DP's connected, so I am sure that its not a DP issue.... (I normally do all my blind pre-programming without the DP's, as its faster).

    The way to get the best performance out of the Hog-3 in a playback situation is the "Kylie Method"...

    1)Back-Up Your Show.
    2)Garbage Collect (and with this new software... wait a bit once its done or it will crash)
    3)Check Integrity (wait a bit afterwards.. for the same reason as 2)
    4)Shutdown the Console
    5)Pull the mains out of the back of the DP's
    6)Count to 10
    7)Power up the console
    8)Load the Show
    9)Once the console has loaded the show and all of its toolbars.... power up the DP's
    10)Wait until the DP's have loaded the show and are both Online.
    11)Go to the 1st Show Page
    12)Hit GO a couple of times on every cuelist
    13)Pig+Release
    13)Goto the 2nd Show Page... & repeat 11 & 12 until you have Loaded all the used Cuelists into the DP's
    14)Run the Show

    I get all my Operators to do this during changeover on every tour we send out (and have done for the past 3 years) and it makes for a super-fast playback console.

    I hope this helps.....

    D
  • dandan Registered User, Hog Beta
    edited May 2007
    Jason.....

    Well, when I was a lad in the days of 1.2, there were only really 3 touring shows being run on the console.... Kylie Minogue, Simply Red & UB40..... and as we were all field-testing the software, with new builds released almost daily... we swapped tips and tricks for solving bugs and stability issues...
    .. this method was pioneered by the Kylie boys... and the name has stuck.

    D
  • SourceChildSourceChild Registered User
    edited May 2007
    Dan! I didn't realize there were others as obsessive as I was about this. Maybe we can get this adopted into the Manual so that people don't think I'm crazy when I propose it!
  • jabadgerjabadger Registered User
    edited May 2007
    Ugh, I was starting in on all this on v1.1 (March 03) - I do not miss those days. I'm fairly confident I've lost some years due to stress with this thing (Gawd has it truly been 4 years? Kill me.)
  • Marty PostmaMarty Postma Registered User
    edited May 2007
    Yeah Dan, I must admit this method has worked very well for me ever since you taught me that a few years back.

    I would add though that any Virtual Lists and/or Scenes that are executed from comment macros or wherever especially if the Lists are chases should be triggered and let run for about 15-30 seconds individually. This seems to help keep playback running smoothly if the DP has had a chance to run them for some reason:dunno:
  • teericksonteerickson Registered User, HES Alumni
    edited May 2007
    Playbacks (scenes or lists) are sent to the DPs when they appear on the current page on the console. You shouldn't have to play any of the lists on the console to ensure that this happens.

    Since virtual lists and scenes don't appear on pages, they don't get sent to the DPs until they are actually played. The data is sent as soon as the list is triggered, so you shouldn't have to wait once you've fired them. As soon as you see feedback that the list is playing you have confirmation that the DP has been sent the information about the list and it will request any other data that it needs.
  • z6p6tist6z6p6tist6 Registered User
    edited May 2007
    Dan,

    Have you tried setting up a comment macro to fire all of the cuelists & scenes at once? If it does the same thing (i.e. loading all lists and scenes into the DP) then it would save your operators the time of going through every page.

    PG
  • teericksonteerickson Registered User, HES Alumni
    edited May 2007
    Good suggestion, Phil.

    You could set up a list that fires all of the playbacks you need and then does a RA (release all) after a 5s wait.

    You could even fire this list as a startup macro from the preferences screen so that it runs when you load your show.
  • z6p6tist6z6p6tist6 Registered User
    edited May 2007
    Exactly.

    Though I don't think you could put this in a Startup Macro if you were using the...

    kylieminogue_wideweb__430x308.jpg


    ...method.

    In fact, I don't think I've ever used any startup macros that attempt to fire any lists or cues.

    Are there any problems with doing this? Does the desk wait to fire these macros until the processors are loaded?

    PG
  • teericksonteerickson Registered User, HES Alumni
    edited May 2007
    By default, the console will not fire the comment macro until all nodes (DP2000s and MIDI / Timecode processors) on the network have been found and have loaded. A dialog box will come up that shows the status for how many have been found / are loading / are ready and this will go away when the comment macro fires once they are all online.

    If you force the comment macro to fire before the nodes have loaded, it may or may not work. If at least one node is online, other nodes will catch up to it and play active lists when they join, but since I suggested using a RA macro 5s after the gos are sent, there may be nothing playing and some nodes may not get all of their data.

    Nice pic, by the way. I guess I need to go find a new Halloween costume, since she's wearing the one I was going to use.
  • jxgriffijxgriffi Registered User, DL Beta, Hog Beta
    edited May 2007
    teerickson wrote:
    Nice pic, by the way. I guess I need to go find a new Halloween costume, since she's wearing the one I was going to use.

    Ok...THAT was a visual I didn't need....
  • Marty PostmaMarty Postma Registered User
    edited May 2007
    z6p6tist6 wrote:
    Have you tried setting up a comment macro to fire all of the cuelists & scenes at once? If it does the same thing (i.e. loading all lists and scenes into the DP) then it would save your operators the time of going through every page.

    Practical experieince tells me that this is probably not a good idea;)
  • nibornibor Registered User, Hog Beta
    edited May 2007
    1 H3 the latest release
    1 mini wing
    1 DP2k
    ok I'm programming a dance proformance
    and all was going well
    then there was this strange slowing it was on everything faders HTP's
    it all ! I took out the trash, still slow and then I renumberd a lot of point cues and the speed picked up it realy put the poop's up me for a while
    more programming all week I will keep you posted (it's not the bigest
    rig a the world this is strange
  • SourceChildSourceChild Registered User
    edited May 2007
    z6p6tist6 wrote:
    Have you tried setting up a comment macro to fire all of the cuelists & scenes at once?

    Dan, I agree but a little bit differently.

    I just built a cuelist of comment macros am made it list 1. Since I have a hundred plus cuelists and scenes on one of my show, I made this one a long one.

    Cue 1: Empty
    Cue 2: GL2
    ...
    ...
    ...
    Cue 101: GS1
    Cue 102: GS2
    ...
    ...
    Cue 151: RA

    Yes, this is a 150 cue cuelist and I set a 5 second wait time between cues. It takes 13 minutes to run but this is the kind of cue I would run with GM at zero or Live parked when doors open anyway so my show would be fresh and ready.

    It took me about 15 minutes to build from home on my pc but from now on, I'll merge this into every single show I ever do again. The beauty is that I can just delete the lists and scene numbers I'm not using.

    I am even considering another list that does CP for pages 1 thru 50 as a quick way. Of course this still doesn't get the v-list or v-scenes but for a quick reboot it takes less time than method one.
Sign In or Register to comment.