ESEQ is defining 1 channel too many

[nmiller0113]

I double checked my custom model named "tuneto" was built properly with 109 pixels before opening this.  I actually first reported this issue on the FPP Forums:

http://falconchristmas.com/forum/index.php/topic,8563.msg79652.html#msg79652

as I thought it was an issue on their end but Chris confirmed the channel count in the ESEQ was being built as 328 channels instead of 327 channels as it should be for 109 pixels.  So now I'm hoping that someone else here can solve this problem

Here is my rgbeffects file:
https://drive.google.com/file/d/1SbWExL3J2l3KpQm37Bvxj0yxvf7TZGNC/view?usp=sharing

And the ESEQ I am creating from the "tuneto" model:
https://drive.google.com/file/d/1oXS44ZzswCqOAmEyUXx_iH0ljGaoPKg9/view?usp=sharing

Thanks!

[Gilrock]

There was a change to make the outputs common many months ago that introduced an off by 1 problem that impacted several spots in the code.  So first I gotta ask have you deleted the ESEQ file and recreated it with the latest beta version?  I don't have access to the code right now to verify anything.

[nmiller0113]

Sorry Gil, I should have stated that I did try to recreate the ESEQ file with the latest from a week ago and it didn’t correct the issue.

[Gilrock]

Ok I tracked this down and we are rounding the number of channels to a multiple of 4.  This change I believe was done to fix the issue where the FSEQ file was calculated as not being the correct size when you open the sequence so we would dump the data due to channel number mismatch.  I'll have to see what Keith thinks about this.

2017.38  Nov 25, 2017
   -- bug (keith) Fix problem where FSEQ data is dumped on load due to mismatch in size ... roundto4 problem

[keithsw1111]

this should be fixed in .2

[nmiller0113]

Unfortunately, this is the first time I've had an opportunity to test this.  I am creating a bunch of single channel A/C elements and make them ESEQ's to run in the background.  They are triggering the model 1 channel higher than the model I created the ESEQ in.  I've confirmed the channel is correctly set up in the layout and controller, and in the FSEQ's or by manually triggering the model in the Test tool, both work fine.  I'd be happy to provide an ESEQ for review.

I also submitted a bug for this https://github.com/smeighan/xLights/issues/1289

[Gilrock]

I'll take a look in January and maybe you can test again next October.

[nmiller0113]

Haha, yeah I get it, but truth is I had my display down and stored away by the time the fix was released because I had a big family vacation planned right after new years day.  This was the first opportunity I had to test it again.

[Gilrock]

Just gap your channel definition.

[nmiller0113]

This was just reported on Facebook and it seems, based on the video here https://www.facebook.com/groups/xLights/permalink/1965422423493503/ ,that it is not the same problem as last time, it just seems very similar.  The ESEQ appears to work correctly in FPP but not in xSchedule.  So maybe it is due to a problem in the way xSchedule is reading the ESEQ file.

[nmiller0113]

Unfortunately, this is the first time I've had an opportunity to test this.  I am creating a bunch of single channel A/C elements and make them ESEQ's to run in the background.  They are triggering the model 1 channel higher than the model I created the ESEQ in.  I've confirmed the channel is correctly set up in the layout and controller, and in the FSEQ's or by manually triggering the model in the Test tool, both work fine.  I'd be happy to provide an ESEQ for review.

I also submitted a bug for this https://github.com/smeighan/xLights/issues/1289

I was incorrect.  This is not the same as the last issue.  As Gil pointed out on Facebook, the problem stated in this thread was an extra channel issue and the problem I'm experiencing now is a starting on the wrong channel issue.  Two completely different problems!  I'll update the bug accordingly and mark this thread as SOLVED!  Sorry for any confusion, I should have known better than to reply to an old thread...rookie mistake...won't happen again!