Video in two layers of model with HSV blending crashes 2017.6 *SOLVED?*

[johnty]

I have a 40 second video of rippling blue water inserted on two layers of a multi-tree model between a 20 second timing mark.  I'm changing the Hue of the second layer and playing with different Layer Blending settings to see what colors I get.  xLights has crashed about a dozen times in the last hour.  I can't repeat the crash with exactly the same click sequence on HSV sliders movement, Effect1/Effect2 Layer options and Color window Update button but a combination of those will within a few minutes bring up the Debug Report.  The current one attached was caused by changing the Value Slider and clicking the Color Update button.

Log files, Package Sequence and screen capture of Color and Effect Settings attached.  If the dump doesn't point to a problem area I will keep trying to make a 100% repeatable crash.

[keithsw1111]

I tried to reproduce the problem and I dont seem to be able to. By the looks of things it is some sort of race condition so it is going to be difficult to reproduce consistently.

[johnty]

I tried to reproduce the problem and I dont seem to be able to. By the looks of things it is some sort of race condition so it is going to be difficult to reproduce consistently.

Agreed.  I have a clue and a fairly repeatable crash.  I have simplified the test video and number of items clicked to cause the dump.  New files attached.

Clue:  when the video is played on only one physical model (a 100-pixel tree) the program is solid. I can adjust any Color slider and it never crashes.  When the video is played on model groups, two in this case, it doesn't take long to crash.

Open my A_CrashVideo program, click only on the video icon in the Even Trees timeline, then click on the Odd Trees video icon, Even Trees icon, Odd Trees, etc.  Back and forth for maybe 10-15 times.  I always get the Debug report or xLights just completely closes within that time frame.  (I'm using two monitors for various control windows.  If that's a problem I'll redo on one screen.)

If you can't duplicate, it could be our machines.  I'm running Win7 Pro 64-bit on an Intel Dual-Core E5300 @2.60GHz.  That's pretty slow compared to new machines and since video spread over model groups is very CPU intensive maybe internal processes aren't "catching up" and staying in-sync somewhere in the line.

[johnty]

Apparently the bug is hardware dependent.  I tried the program on my Theater PC which has an Intel i7-3770K @3.5GHz with eight CPUs running Win8.1  Same program with the same settings and I clicked between the Video icons on the two timelines, changed all of the Color HSV settings, different Layer settings, etc.  It never crashed.

Back on my slower 2-CPU machine, xLights crashes within 15 seconds when playing with this video.  Interestingly, the Resource Monitor on the i7 shows all eight CPUs being briefly maxed-out when changing the video playback settings.  On the E5300 the CPU usage is constantly pegged at 100%.  I don't think it has a fighting chance - it just can't keep up.  Could be the way Win7/Win8.1 handle error exceptions but I doubt it.

Since the computer hardware plays a key role in xLights operation, the problem probably isn't solvable. The solution in my case is Save early, Save often.

[johnty]

In one last attempt to verify that my problem is a hardware issue, I started my slow dual-boot PC into Win10.  Using the same test program and video I tried to cause the crash that always occurs in Win7 on the same physical machine. 

xLights performed flawlessly.  As I changed HSV sliders, my model groups in the House Preview window flickered on and off much more than they did on my faster PC but they would stabilize and keep running.  I could do nothing to crash the program. 

So, good news, it's not hardware. Bad news, it's not hardware.  This is probably going to be tough finding the answer.

[Gilrock]

The best thing that could happen to you is to accidentally spill coffee in that pc.

[johnty]

The best thing that could happen to you is to accidentally spill coffee in that pc.

But everything seemed OK after the Jack Daniel's bottle sitting on the PC toppled over.


I finally crashed xL in Win10 on the slow machine.  Much harder to do but it finally happened as I moved the Hue slider back and forth very rapidly.  I've been looking at the log entries under both versions of Windows and there's occasionally one very interesting line...

[WARN] Frame #63 render on model Even Trees (380x386) layer 0 effect Video from 0ms (#0) to 14850ms (#296) took more than 150 ms => 245ms.

150ms is three updates to the pixels at the usual standard of 50ms that many people use.  Most of the time in Win10 that warning never occurred as I adjusted settings.  In Win7 they appeared most of the time.  Could be the efficiency of Win10 code over Win7.  And, if renders of a video in real time start taking too long, can that lead the the "race" condition Keith mentions?  Who knows.

This thread is a waste of bandwidth and of little interest except to tech weenies like me.  I've solved the issue to my satisfaction and concluded it's a combination of hardware and software.  xLights is an amazing program and 99.99% bulletproof but if pushed too hard, in real time, on a slow machine, under certain operating systems, it will crash.  Tough noogies.

Two lessons learned about my development platform...

1.  Make real-time adjustments to multiple videos concurrently playing on model groups SLOWLY.  If playback in the Model Preview window isn't jerky things tend to keep running.
2.  Never set your cocktail on top of the PC's case.


 

[Gilrock]

You're mixing up a couple different things.  The 50ms timing intervals is not related to the render time.  Render time can be as long as it needs to render.  That was almost a 15 second effect so it had way more than 3 50ms divisions to process.  Being over the 150ms warning isn't always a problem especially for longer effects.