Messages

1

Bugs in xLights/Nutcracker / Re: Enabling Render Cache can crash xLights

« on: July 21, 2021, 02:42:53 PM »

Keith, did you get my PM?

2

Bugs in xLights/Nutcracker / Enabling Render Cache can crash xLights

« on: June 05, 2021, 02:13:06 PM »

I bought two sequences from one of our well known vendors last week, unzipped the files and executed both with xLights.  One rendered as expected, the other caused xLights to hard-crash. The sequence window just disappeared, no crash dump file.  After many hours of testing each model in the offending sequence I determined that there was nothing wrong with it.  Running the program on two different hardware platforms with different versions of Windows, the same problem occurred so it wasn't my environment.  Doing regression testing on past versions of xLights I found that it rendered without a problem in 2021.5, hung the program in 2021.6 and crashed in 2021.7 through the current release.  Looking at the release notes for these versions I found the following?

2021.06 March 1 2021
   -- enh (kevin)  Add Circles and Shatter transitions
   .
   .
   -- bug (dkulp)  Fix issues with effects that need to render on the main thread being rendered     
      WAY too often if "Per Model" used.
2021.07 March 2 2021
   -- bug (dkulp)  Fix potential hang with "Per Model" render styles
   -- bug (scott)  Fix crash in swap transition
 
This correlated correctly with the render hanging in 2021.6.  I then started to changed options in the Preferences tabs.  I've always had Render Cache Enabled since the feature was introduced.  I set it to Disable and the sequence rendered to completion.  I've had xLights hard-crash now and then this year but never when doing a Render All.

I can't attach the paid sequence to this post but if a developer wants to look into it, the vendor has given me permission to send it to you via PM.  The crash is 100% repeatable and I also have some other clues about just what is happening.

If anyone is experiencing inexplicable crashes when sequencing and you have Render Cache Enabled, set it to Disable and see if the problem is fixed.

John

3

Bugs in xLights/Nutcracker / Global FPP Proxy setting does nothing

« on: May 27, 2020, 03:27:41 PM »

I?ve got my FPP set to bridge mode and talking to it from xLights via its wireless connection: 192.168.0.20.  The Ethernet port on the Pi is hardwired to my one of my four controllers:  192.168.1.209

My test program sets the Global FPP Proxy field to 192.168.0.20, I start the sequence, turn on the Output to Lights icon and nothing happens.  When I enter 192.168.0.20 into the FPP Proxy IP/Hostname on the .209 controller detail page, all of the pixels light up as expected.  I can leave the Global field filled in or not, makes no difference.  I only see data updating on the FPP Status page and pixels working when the .20 IP is on the actual controller page.

The test program is attached.  Please let me know if this situation is operator error or something in xLights.

Thank you.

4

Enhancement Requests / Add FPP Proxy IP option in Setup Bulk Edit

« on: January 21, 2020, 05:43:31 PM »

I’m working on this year’s show and moving controllers between a dedicate NIC on my PC and a FPP in Bridge mode for pixel testing.  Moving the controller Ethernet cables is easy but in the xLights Setup tab I have to update dozens of Universes one line at a time to add or delete the FPP Proxy address to point the data to the correct output.

Could you add a FPP Proxy IP field to the Setup Bulk Edit option so that multiple controllers could be updated with a single click?

Thank you.

5

Bugs in xLights/Nutcracker / Re: Force Local IP address not sending data to controllers

« on: December 03, 2019, 11:32:47 PM »

It doesn't prevent anything, it just changes where the data goes.   

Now I understand.  I thought data would go to both the proxy port and local NIC card but I guess there are configurations where that might cause problems.  I was running FPP in Bridge mode and it worked except for the F16V3 detail pages which appears to be fixed with a Falcon firmware update.

Until I can get that working, changing the network from the Pi to the PC requires deleting or adding dozens of FPP Proxy IP addresses one line at a time.  A Bulk Edit for that Setup field in xLights would be most beneficial.

Thanks for your help!

6

Bugs in xLights/Nutcracker / Re: Force Local IP address not sending data to controllers

« on: December 03, 2019, 05:54:44 PM »

The page display problem was fixed in FPP 3.5.4 I believe.

The F16V3 status page now displays correctly in FPP 3.5.5 but the E131/Artnet and String Ports pages do not.  I'm creating a post of the FPP forum since this problem is off-topic.  Still, it is not a trivial exercise to move between the Pi and the PC to debug things.  A FPP Proxy option in the xLlights Setup Bulk Edit option would be nice if an IP address in that field is going to prevent data output to the NIC.

7

Bugs in xLights/Nutcracker / Re: Force Local IP address not sending data to controllers

« on: December 03, 2019, 02:22:24 PM »

Do you have "FPP Proxy" settings set for any controller?   That seems to be the only change between .31 and .32 that would have an impact on output.

That was the problem.  Deleting the proxy IP does let data flow to the controllers.  But does that have to be an either/or situation?  I've been running FPP in Bridge mode to test sequences from xLights but there's a problem with seeing controllers via proxy in FPP (Falcon F16V3 pages don't show correctly).  After I get some controller settings fixed and tested from my PC I'll move the LAN back to my Pi but all of the FPP Proxy settings in Setup will have to be re-added.  Is a mod possible to xLights to have the FPP Proxy IPs present and still have data going to a Local Ethernet card?

8

Bugs in xLights/Nutcracker / Re: Force Local IP address not sending data to controllers

« on: December 03, 2019, 01:06:41 PM »

Go back to v1 files.

That doesn't fix the problem.  I tried all four FSEQ Version settings with no luck.

9

Bugs in xLights/Nutcracker / Force Local IP address not sending data to controllers

« on: December 02, 2019, 11:38:07 PM »

I have my controllers on a LAN connected to a second NIC card in my Windows 10 machine with an IPV4 address of 192.168.1.100.  With a browser I can see all of my controller's status pages so I know that my PC is talking to them.  In my Settings I have Force Local IP checked and the above IP address is selected.  When I play a fully rendered sequence in 2019.67 (64bit) and click on Output to Lights, nothing happens.

In regression testing, I find that 2019.31 works correctly.  Version 2019.32 does not nor does any newer release.  FSEQ Version is V2 in .31, V2 ZSTD in .67.  Nothing else is checked in Settings except for Save and Backup.

Could you investigate?  Let me know if you need more info.

10

Enhancement Requests / Re: New Settings entry: Default Audio Volume

« on: May 20, 2019, 01:54:45 PM »

I took a stab at implementing this feature, and my pull request (the code changes I proposed, for those who aren't familiar with github lingo) was accepted and merged, so you should see this topic addressed in the next release. There won't be a separate menu selection for default audio volume, but whatever you set in the existing "Audio" menu will be saved and restored at the next launch of the program.

Even better.  Thanks TypingOffKey!

11

Enhancement Requests / Re: New Settings entry: Default Audio Volume

« on: May 17, 2019, 09:06:08 PM »

The tacit response is overwhelming.

What do you prefer.  I can give a smart remark when I don't like an idea or I can say nothing.

A smart remark which is your forte with perhaps a few words of why it's a bad idea.

12

Enhancement Requests / Re: New Settings entry: Default Audio Volume

« on: May 11, 2019, 11:57:05 AM »

The tacit response is overwhelming.

13

Enhancement Requests / New Settings entry: Default Audio Volume

« on: April 30, 2019, 11:32:19 PM »

I usually play sequences with the Audio set to Very Quiet since I’ve heard the music for the effect dozens of times.  When I want to hear it at full production volume I switch to Loud.  When I open xLights at midnight and forget to change Audio from Loud to Very Quiet I’m blasted with music.  Last year I asked if the last Audio setting could be saved when exiting xLights.  Keith said no, the Very Quiet setting was primarily for the Zoom call.  Gil correctly pointed out that I could open Windows Volume Mixer and set xLights’ volume at a lower level.  True enough but then I have no headroom to make it louder without clickety-clickety back into the Volume Mixer.

So, how about an entry in Settings for Default Audio Volume?  Default would be Loud so the addition wouldn’t affect anybody unless they wanted to take advantage of it.  I think it would look like this in the drop-down Settings menu:

Default Audio Volume               >      •  Loud

                                                            Medium

                                                            Quiet

                                                            Very Quiet

Programming should be simple.  At start-up, read the Default Audio Volume setting, set the switch in the corresponding Audio setting, done.  This method has the added advantage that it is persistent across a crash in xLights.  Should work fine, last a long time.

Please?

14

Bugs in xLights/Nutcracker / Re: Text mapping to Matrix Group problem

« on: November 25, 2018, 06:37:04 PM »

What controller. Can you apply dimming curve on the controller. Or in the player.

Controller is a Falcon F16v3.  Dave Pitts said there's no way to adjust individual red, green and blue sub-pixels, only at the macro level.  I'm using a Pi and FPP for the show.  There was talk of having sub-pixel dimming curves in 2.4 but it hasn't happened.  Attached is the dimming curve I'm using for the "new and improved" pixels to match the others.  I don't know of any other way to make all of the lights look the same.

15

Bugs in xLights/Nutcracker / Re: Text mapping to Matrix Group problem

« on: November 25, 2018, 04:13:59 PM »

Yeah that matrix is never going to work as a group ... why do you need to model it as 2 rather than 1 matrix?

I didn't know that vendor had changed color balance of "new model" pixels this year which I used to build right half of the matrix.  Had to make two models to set different Dimming Curves for each side to make entire matrix look like the same pixels were used throughout.

Text effect is the only casualty of doing a model group.