Crash upon hitting PLAY

[jamills6377]

Installed the new executable ... it played for about 10 or so seconds ... then crashed. Attached is the crash report/log.

[Gilrock]

Yeah that looks exactly the same so I can't tell whether it might not have picked up the changes when I built it.

[jamills6377]

I made certain that I had the version that you emailed to me. Will you be sending me a rebuild?

[Gilrock]

I don't need to Keith issued a new release that has everything I changed.  If that doesn't work maybe try creating a 100ms sequence so it won't try to pump data out so fast.  We may just not be optimized for trying to pump that much data out but I'm not even sure where you left off.  How many channels are defined in the sequence you are trying to play?  And I don't mean how many models have effects because what matters is how many channels are defined in setup.  I'm also not sure if disabling an output reduced the size of the FSEQ file it may just keep xLights from pumping out the data when you playback in xLights so you can experiment to find out whether the FSEQ file size changes.  Cause I can't remember if you actually created a brand new blank show directory when I asked you to just get on output working.

[jamills6377]

I did make the new show directory and only had the one 16-output controller defined in it. But just to be certain, with the .34 version now available. I will test again...and try to be more clear about what exactly is defined. Thanks

[jamills6377]

OK - I erased the old "new show" directory and created a new one. Added only one Pixie16 controller to it and placed that matrix onto my layout. I made a new animation and placed a color wash on the matrix - it lit up but was slightly blinky - like it was bickering ever so slightly.
I changed the color wash to the aces effect and selected a face (which I had set up with all o its appropriate graphics - the mad scientist images you've already seen me use)..... he displayed on the matrix (without me pressing play) for a couple o seconds then the debug screen popped up.
I have attached that debug report for you to see as I noted the Crash Handler had been called in it.

[Gilrock]

Didn't everything work when you pretended it was a Pixie4 and a Pixie8?  I'm just not sure I can debug this without having a Pixie16 myself.

[jamills6377]

I don't recall ever trying to put a face on it - just color wash and stuff like that. Ill try the face again on a 4 and 8 to see what it does.

[Gilrock]

I helped someone yesterday with a Pixie8.  He was running at 115Kbaud.  Simple effects like On and Bars were working fine but when he dropped a Butterfly he got lag but he wasn't crashing.  I'm pretty sure if he switched to a 512Kbaud dongle his would have worked.  So the point is a Butterfly effect is a pretty good stress test for the LOR protocol because it has so many different colors on different channels that it brings out the inefficiencies of the protocol.  So what I'm hearing is you had some lag with ColorWash but no crashing.  Then you tried a more complex effect and it couldn't keep up and crashed.  You may just be crossing a channel limit that we can't handle.

[jamills6377]

as a Pixie4 - color wash worked until I added a second color then it flickered.
Face effect crashed it.

[jamills6377]

Something else I noted - not really completely related --- when it crashes and I restart xLights I get an error message when I press the white light bulb to turn it yellow that the port is in use - so it would seem to me that the crash handling routines don't free up the com port(s) that are in use.

Before testing again, though, I always clicked on white bulb - got message - clicked on black bulb to free them up - quit xLights - started up xLights and then did not get that error message --- just to be sure I wasn't starting out already compromised.

[jamills6377]

A thought that popped into my head as I wondered about all of this just now ---- I have been doing all of the testing on the Windows machine with the RS485 dongles - but if I am not running the LOR software (which is Windows only) and since xLights itself will run on the Mac - can I plug the RS485 dongles onto my Mac and run from there?? And, if I can, do you think that'd make any difference?

I didn't connect them because I didn't want to let the magic smoke out of anything just in case!

[Gilrock]

as a Pixie4 - color wash worked until I added a second color then it flickered.
Face effect crashed it.

I know running a Pixie4 will not crash my setup so I'm not sure what is going on.  There was nothing useful in the file you attached.  I also have no idea whether you can hookup those USB dongles to a MAC.  I can't believe any hardware damage could occur its probably just either going to work or not work.  Depends on whether the MAC has the driver for the serial to USB chip LOR is using.

[keithsw1111]

It seems to be crashing in OutputManager::SetManyChannels which is odd ... i would have thought it more likely to crash in the class for the LOR output.

[Gilrock]

So did you give up and just use LOR?  I saw you post that you wanted to stick with all LOR software if you could or were you just trying to keep the LOR wolves off your back...lol.

I've been testing and the only time I can get a crash is when I define a ton of channels and then turn off Output to Lights.  It appears that if the interface can't handle the amount of data its stacking up in the output buffer of the serial driver and we weren't giving it long enough to transmit all the data when we closed the port.  I'm trying to figure out a good way to not let it stack up but that will mean skipping frames when its too much data.

I did some testing and with a Pixie16 defined at 300 channels per port which is 4,800 channels it was averaging 13,250 bytes per frame when I used a Butterfly effect.  Then I switched to a Bars effect and it was only 320 bytes and then 3 frames of 0 bytes.  So that's what I mean about their protocol its highly depending on the number of different colors on the channels.  An effect like Bars with lots of channels having the same color is more efficient than E1.31 protocol but use a Butterfly and its like 3 times worse than E1.31.

So using a 50ms sequence timing 13,250 bytes per frame would take about 5.1 seconds to transmit 1 seconds worth of data at 512Kbaud.  So depending on the effect you might be limited to 1000 channels at 512Kbaud but more channels for simple effects with a lot of the same color.  Now LOR might be more efficient because they have that new enhanced protocol where they apparently tried to overcome these shortcomings but its not like they want to share their scheme to help us out.  They want to lock you into their hardware and software and its working for some people.  If they were purely a hardware vendor they would publish that protocol because it would be in their best interest that everyone using their hardware had a good experience no matter which software they use.