slight intermittent "freezing" of lights

[rickswa]

Hey All,

I was wondering if someone had any idea how to fix an issue I'm having.  I'm running my show from a laptop with xschedule64 in the standalone mode.  I'm running everything in multicast and have one cat 5 cable running out to a falcon f16v3 and 1 output to 9 LOR boxes on the DMX side and then 4 pixel arch outputs from the main f16 board and also 4 expansion cards to various pixel elements.  The issue I'm having is every now and then, there is a slight "freeze" in my sequences but then it resumes normal and in sync.  The audio doesn't freeze, just the lights.  It's a very slight freeze, probably in the neighborhood of a half second or so, but still can be noticed.  When I looked in the xschedule log, there were multiple [warn] and [debug] messages from last night with the repeating one of "frame rate greater than 200% of expected."   I'm not sure if that has anything to do with it, and if it does, i have no idea how to fix that.  I'm just worried with this slight lag this season, that when I use the other 4 expansion cards next season, it will get worse.  Just curious if anyone has experienced this type of intermittent short span "freezing" or any idea how to fix it.  Thanks for any help.

[allknowing2012]

Try running with task manager up and visible .. see if something is coming on .. like dropbox, virus scans, etc. Seems like a bottleneck there somewhere.

[keithsw1111]

I have seen a few people having either issues with micro-pauses or slowness with running sequences in xSchedule.

There are many possible reasons why this could happen so let me run through them to help you troubleshoot.

First of all keep it simple. Set up a simple playlist with just FSEQ and MP3 audio tracks ... drop all the other stuff and show that playing a simple sequence works. Dont be tempted to use other music formats for this test as MP3 is by far the most commonly used and thus least likely to be the source of your problems.

If even a simple schedule pauses then we have to look at bit deeper.

Essentially all xSchedule does in each frame is read a frame of data from the FSEQ file and then send it out to all of your outputs. There is not a lot that can go wrong. Periodically it also does some UI upkeep.

So lets look at each one of steps.

Reading the FSEQ file from disk
   - Make sure the FSEQ file is on a local fast disk. Avoid network drives and even memory sticks (as the USB bus may have issues)
   - Make sure nothing else is likely to be accessing the files so shut down dropbox and similar services that might be accessing the files.
   - Make sure your virus scanner is not slowing down access ... consider turning it off and testing without it

Writing to the outputs   
   - If you have multiple active network connections try disabling the one not used by your show
   - If you are internet connected ... try disconnecting to the network
   - If you are running multicast to wired controllers try making them unicast
   - If you are using serial devices try disabling those outputs.
   
General load
   - Check task manager (the details view) ... sort by CPU ... is the there any other program spiking CPU when the show glitches
   - Check memory utilisation ... once you are using more memory than your machine has things will slow due to the need to swap memory to and from disk
   
Periodic Processes - 1 second
   - Every second on the second xSchedule will do a bunch of UI updates and send out status information to any web clients. Consider disconnecting web clients.
   
Periodic Processes - 1 minute
   - Every minute on the minute xSchedule will check all the schedules to decide if any of them should start or stop. If you have more than 2-3 schedules consider disabling most of them.
   
If none of the above help then consider the overall performance of the machine you are running on. Is it generally a very slow PC ... could there be broader performance issues with the machine which are impacting your show. Maybe consider rebuilding the machine or removing all that accumulated software as many programs love to add programs that run in the background and slowly grind performance of your machine into the ground.

[rickswa]

WOW!  THANK YOU so much for the detailed responses.  I went in task manager and when laptop is running only with xschedule running idle, my memory is at 49% useage.  I previously had all wifi shutoff as well.  I took off and disabled as many programs as I can but it's still right around 48% memory usage since I can't get cortana to shut off permanently.  I have been running the show with xlights on the hard drive but the sequences on a USB stick so I could edit them between machines if I wanted.  But, as you listed, this could be one of the causes for the issue so I'm now transferring all the audio (mp3's) and fseq files I'll use in my show over to the hard drive and will let you know the outcome.  Thanks again for the great replies.

[rickswa]

I'm now down to wondering if it's just the laptop or the multicast issue.  I have 9 LOR boxes and all the other pixels running in multicast.  When I put the show from the USB stick to the HD on the laptop, it got worse.  a lot worse.  So I quickly switched it back to the xlights software on the HD and the show on the USB stick.  I had thought about getting into the pi setup anyhow maybe this is a good time.  Do you think the pi would be able to run this with my current multicast setup or would an improvement to the laptop be a better option?  Thanks again for the help.

[keithsw1111]

Sure the Pi will run it ... but I worry about your obsession with multicast ... the only time multicast makes sense is if you are using wifi pixel stricks or multiple controllers using the same data. In every other situation multicast is either worse or the same in performance. Large numbers of multicast cause lots of issues.

[rickswa]

Thank you.  I went the multicast way just because it seemed easier to setup and I could just send the info out to all the boxes.  If I switch to unicast, does that mean I have to redefine everything in xlights and the f16 as well as re-assign the LOR boxes I have?   

Last year, everything worked great with no delay at all.  This year, overall I replaced 4 LOR 16 channel boxes and two CCR's with a total of 4152 pixel nodes (a mix of WS2811 and INK 1003).  One interesting thing is that when I tested the pixel megatree and arches I added this year earlier in my basement before setting them up outside, there was no lag at all.  Wouldn't the same amount of data have been getting pushed out?  I had one of my 396 pixel frequency signs, the 2160 pixel megatree and 4 150 node arches all running during testing in the basement with no delay.  I just can't seem to come to grips with this lag.  Its basically where if there is an arch chase, it will skip certain pixels and resume "down the line" .

When I checked the laptop just now with the show running, it's only using 4% of the 2.3Ghz processor, 51% of 4GB ram, 1% of the GPU and the ethernet showed sending at 3.7 Mbps.  IPv4 showed the address of the F16 and IPv6 showed some address I didn't know. 

I'm just worried about the involvement of switching over to unicast since after reading all the potential problems people had with it, I initially went with a multicast setup.  If this seems to be the overall problem, then I guess I'm left with no other option.  Thanks again for all your help.  IF I did the pi to run it, is it as simple as replacing the PC with the Pi and the FPP software?  Would that let me still just run one cat 5 out to the f16 and then from there daisy chain my LOR like now and use the expansion cards?

[rickswa]

SOLVED!!

Thanks for all the help Keith and Allknowing!  I really really appreciate it.  I hate to jinx myself but it seems I may have the issue fixed.  This is going to sound about as dumb as they come, but I switched xlights and my sequences over to my macbook pro running windows 7 via bootcamp and the latency issue seems to have vanished.  There was only one small jitter over the course of 5 songs so far.  Hopefully this continues and I can finally get some rest.  The funny thing is that I bought the PC laptop specifically for this task and it's much newer than the mac.  I think the ethernet card is probably junk.  I'm also switching over to the pi for sure since I have one running retropie right now anyhow.  Thanks again for the huge help and sorry this was such a long post for such a dumb problem on my part.

[Rhino_111]

I am having this issue now on a very basic setup.  I am running xlights 48 on an iMac and it is only controlling a single 180 degree mega tree running in unicast.  This is the second year I have used the tree as I am slowly getting into this hobby more and last year things worked very easily.  Now, when running xschedule there will be random freezing in my sequence at random times.  I have followed as many suggestions in the previous posts and do not have any other network or WiFi going to the iMac.  Just an Ethernet cable directly to the controller for the mega tree.

Do you have any additional suggestions that I can try to help eliminate this freezing issue?  Thank you!

[keithsw1111]

My suggestion is to grab me at a time on zoom and we can work through your issue.


Sent from my iPhone using Tapatalk