FPP and xLights Channels Out of Sync Due to USB DMX Dongle

[jnealand]

In my pixelnet world I have have the 1st 512 channels reserved for DMX although I have slowly reduced my DMX channels to a couple in the 17x range.  My controller and network start at channel 1, but model starts at 17x  My pixels start at 513.  For my network I just have 64 universes of 512.   Not sure I understand what your problems really are.

[Gilrock]

Maybe try changing output 1 to be an E1.31 output set to a bogus universe like 99.  Then see if it works.  If so then I think that would prove xLights is not properly handling that DMX output type.

[Gary]

Maybe try changing output 1 to be an E1.31 output set to a bogus universe like 99.  Then see if it works.  If so then I think that would prove xLights is not properly handling that DMX output type.

You mean like in my "DMX to Bottom" image where I shoved it to the bottom?

If so, my pixels behave as expected both on-screen and in the real world.

Either way, I can't keep my DMX stuff in that channel range because, well, it doesn't support such high channel numbers. 

[Gary]

As an experiment, I thought that I'd try taking all my current "live/production" xLights 2017.30-related files, place them into a separate folder, and then restore my backed up xLights 2016.51-related files to my "live/production" folder and open xLights 2016.51 again (I still had it installed in my Program Files (x86) folder) to see how it behaves.

I expected the FPP Testing, xLights Testing, a sample xLights Sequence, and the "real world" pixels to match up, but they didn't, either. What's weirder is that in 2017.30/32, my channels were shifted by 316 (the number of channels I had set aside for DMX), but in 2016.51, my channels were shifted by 512 (an entire DMX universe).

Scratching my head on how my xLights channels were off in 2016 as well, I tried making an FSEQ file out of my test sequence, uploaded it to my FPP and ran it there. The channels worked as I wanted.

Thinking about this more, when I really dove into xLights in 2016, I don't think I had the USB DMX dongle in my Setup tab initially. I initially did a bit of dabbling with xLights running my sequences by sending data to my F16-B running FPP in Bridge mode, but between pixels being out of sync with my music and stuttering due to presumably WiFi lag time (along with Bridge Mode randomly locking up my F16-B), I decided to keep my F16-B in Player (Standalone) mode and rely on my on-screen previews to see what pixels will be lighting up and use FSEQ files to run my show. I also barely used the Test mode in xLights back in 2016.

I still can't explain why the channels were off by 512 in 2016.51 vs. 316 in 2017.30/32, but I won't worry about it now and just stick to using FSEQ files. I've attached a screenshot of my Setup tab in 2016.51... the only difference is that the Baud Rate shows as N/A vs 250000 in 2017.30/32.

In the end, is this entire issue with channels being out of sync if a USB DMX dongle is configured to have its channels before any E131 considered a bug which will be fixed?

[Gilrock]

You realize that if an FSEQ file exists then we use the number of channels defined in that file instead of what you have in setup?  I'm not sure I can trust any of your experiments because it doesn't sound like you realized that when you change the setup you really need to delete the FSEQ files, reopen xLights, and recreate them or things may be invalid.

[Gary]

I wasn't using FSEQ files for any of my experiments until the end. Before that, it was all xLights communicating directly with the controller.

[jnealand]

An fseq file exists if you ever saved the sequence, it will be used by xlights whether you know it or not.  You must delete the fseq while the sequence is closed.  The fseq will be rebuilt the next time you open the sequence and save it.

[Gilrock]

At some point you'll need to get in TeamViewer with others since just talking about it amongst us is not fixing the problem.

[Gary]

An fseq file exists if you ever saved the sequence, it will be used by xlights whether you know it or not.  You must delete the fseq while the sequence is closed.  The fseq will be rebuilt the next time you open the sequence and save it.

What if I have xLights set to Render on Save? Doesn't that create/overwrite the FSEQ file without needing to close out of the sequence and re-open it?

[Gary]

At some point you'll need to get in TeamViewer with others since just talking about it amongst us is not fixing the problem.

Since I have an explanation and workaround by continuing to use FSEQ files in FPP like I did in 2016, I'm happy to work with that in 2017.

That said, I'm willing to have someone to try to work through the issue with a TeamViewer session together. If I don't have any volunteers, perhaps someone can try to reproduce the problem on their setup by adding a dummy USB DMX device (with a few hundred channels assigned) above their E131 stuff and see what happens with their on-screen preview vs. "real world" channel "alignments" when they control their pixels directly from xLights (rather than FPP)?

[jnealand]

An fseq file exists if you ever saved the sequence, it will be used by xlights whether you know it or not.  You must delete the fseq while the sequence is closed.  The fseq will be rebuilt the next time you open the sequence and save it.

What if I have xLights set to Render on Save? Doesn't that create/overwrite the FSEQ file without needing to close out of the sequence and re-open it?

Render on save just updates the old fseq, it does not create a new one.  We have told you multiple times to delete the old fseq.  You have now spent more time arguing against doing that than just doing it.

[Gilrock]

An fseq file exists if you ever saved the sequence, it will be used by xlights whether you know it or not.  You must delete the fseq while the sequence is closed.  The fseq will be rebuilt the next time you open the sequence and save it.

What if I have xLights set to Render on Save? Doesn't that create/overwrite the FSEQ file without needing to close out of the sequence and re-open it?

Yep Jim is right.  Yes it does overwrite the FSEQ but with possibly the WRONG channel count due to what I've been saying.  Glad you're happy to do it your way.   See ya next year.

[Gary]

Note that I'm back to using xLights 2017.32 64-bit for this response...


I would have thought that overwriting an FSEQ file is the same thing as creating a new one. I'm not trying to be difficult and not listen to others peoples' advice.


Okay, rather than using a workaround, I'm curious to see if I CAN get this to work... I closed out of xLights, deleted the FSEQ file associated with the Test Sequence XML file, opened my Test XML and saved it to re-render a new FSEQ file.

Now, to light up my megatree's first strand's first physical pixel is channel 9021 (the Red portion of RGB), which calculates to Channel 8193 (what's assigned to the controller's port 1 for that strand) + 512 (one universe) + 316 (my first Pixelnet channel) = 9021.     Going into the xLights Test window behaves the same way. Does the Test window use a FSEQ file in some way that I need to clear out?


I'm sorry to be causing everybody so much aggravation here and instead of trying everything suggested. I'm on a time crunch here as my pre-sale lights came mid-September rather than the scheduled May/June. Since I can usually only deal with Christmas stuff in the evenings after the kids are asleep and I live on the West Coast (which means that many others are asleep while I'm still up), I'm typing up any responses that I feel would be relevant during the day while I'm at work and away from my light equipment. In fact, I'm typing this just before going to work this morning. I'm not purposely arguing/refusing to take peoples' helpful advice.

[Gilrock]

I don't know if the FSEQ has anything to do with it.  If you just open xLights and go straight to the Test tab then there is no FSEQ in the mix at all.  I was just trying to clarify that it is possible for it to cause a problem.  The issue is I believe we still have scenarios where you can change the Setup and the channel buffers do not get deleted and recreated with the new size.  Same problem used to exist with changing a sequence duration but I fixed that one.  xLights was designed so that if an FSEQ exists then we use it to define the number of channels for the channel buffers so an existing FSEQ overrides what you have in setup.  It was done that way so that you could open an FSEQ and play it.  It's probably nothing to do with your issue.  I thought I would mention it, you would try it, and we would move on but it took forever to get to that point.

At this point only thing I can do is wait till I'm putting up some lights and then try throwing a DMX output at the front and see if it causes a problem.

[keithsw1111]

We are in zoom Friday night your time. Why don't you pop in and ask your questions. See xlights.org for the link.