Issues with AC Tools, primarily "off" tool.

[DoctorWiz]

Describe the bug
The "Off" tool of the AC toolbar is doing strange things, It fails to turn cells off in certain locations, It turns cells on in certain locations. Also, (probably related) Pasting into cells is not accurate, cells in certain locations do not get correct data, they may be on or at the wrong fade level. Seems to be same locations as "Off" tool problem.

To Reproduce
Steps to reproduce the behavior:

1. Open the attached "AC Controller Test" sequence. Go to the "By Controller" view. Expand the xLOR#1 group and the xRenard group.
2. In the xRenard group, expand all 8 of the Tree- Tomato groups.
3. Choose the Off tool from the AC toolbar. Select a large block in the xRenard group (Trees- Tomato) from say from A1 to A5 from 2.0 seconds to 5.5 seconds.
4. Note that on the blue and white trees A2-A5 from 5.0 to 6.0 seconds is already on. The off tool will NOT turn them off.
5. Scroll down so that Tree A7 is displayed. Note that more of the blue and white on those 4 trees now becomes on, including well past the end of the sequence. Scroll back up some and they turn back off except for 5.0 to 6.0 seconds.
6. There does not seem to be a way to turn off those 4 trees blue and white channels from 5.0 to 6.0 seconds.
7. Expand the xLOR#2 group. Try to turn all the trees completely off. Note there is a similar problem with trees B2, B4, B6, and B8 from 5.7 to 6.0 seconds.
8. Choose the select tool from the AC toolbar, and select all of the first 4 rows of xLOR#1 group (Channels "Eaves Chase C9..." from 0.0 to 6.0 seconds. Copy to the clipboard.
9. Click on the first cell of xRenard Tree A2 and Paste. Repeat with trees A3 and A4. Note that the end of the blue and white channel from 5.0 to 6.0 seconds are incorrect and do not match what was copied.

Expected behavior
Expect to be able to turn any spot on any channel off. Do not expect certain locations of certain channels to be stuck on. Expect paste to accurately paste channel states in all cells.

Screenshots
Three ScreenShots with highlight circles have been included with the sequence .zip file.

Versions (please complete the following information):

• OS: Windows 10 and Linux Mint 19
• xLights version: 2019.60 and 2019.59
  I have successfully and reliably duplicated this problem on 3 different Windows 10 machines (ver .60) and in Linux Mint (ver .59). And while the problem is very similar on each of the machines, the affected cell locations are different. Sometimes trying to delete/turn off cells in one time slot makes them turn on in a different time slot.

Additional context
From watching the preview, it seems that the channels are being turned off at the correct times. It seems that the problem may just be with the sequencer's display grid. I hooked up a controller and some test lights and the actual behavior is correct (it is off when it is should be - matches preview) thereby confirming(?) that the problem is only with the display grid and not the underlying data.

Just sent another $50 donation.

Attachments
Sequence with ScreenShots included attached.
AC Controller Channel Test 19d4.zip

[AzGilrock]

Its really hard to tell what's going on cause you have a ton of overlapping channels in your layout. Is that on purpose? Also you have a ton of groups that are not in the Default preview so you cannot see the groups or its members unless you jump back to 2D mode. But you are sequencing on those groups.

[DoctorWiz]

Overlapping channels are because I have in some cases 2 or more things connected to the same circuit/controller output. (examples: 22 candy canes on 4 circuits, 2 disco balls on 1 circuit, 4 snowflake projectors on a circuit...)
I'll make a view without any groups and see how that behaves. But even if that works, it still appears that something is wrong. And I'm still tinkering so if I find a real smoking gun or more direct clues I'll let you know.
Since I notice the problem mainly with the 'trees', the best preview for them is the "forest" preview.

[DoctorWiz]

OK, so #1 I carefully reviewed the layout and the channel assignments and made a few minor corrections. Nothing that I would expect to affect this problem (and turns out, didn't).
#2 I re-did the x_Name_ groups for the controllers so that those groups contained NO subgroups, and in the case of overlapping channels, included only one of each.

It made no difference. I'm still getting the same screwy delete/off behavior, especially with the "Tree- Tomato xxx" channels (which don't overlap) In fact, it's always the same channels (list below) but what exactly what happens depends on where I try to delete or paste and how big/dimensions of the block. Still trying to establish a pattern there. Deleting a tall but narrow block seems a little more prone to misbehavior, as does deleting a block containing the first or the last column. Also of note, when it screws up and fills in most of the row, including beyond the end of the sequence, the row does NOT start exactly at the timing mark/cell edge, but rather about 10ms after. Once it has done that, it is impossible to delete no matter what size/shape block I select, or where it starts or ends. Can't even delete a single cell.

Channels include:
Bushes 4 {D} (W) z_BAD TRIAC UFOs 3 Master Power High Security Lights Snowfall Spots Tomato Trees A2-A8, (B) and (W) - but not A1, and not (R) or (G) Tomato Trees B2, B4, B6 and B8 (V) and (W) - but not B1, B3, B5 or B7 CandyCane03-R3 and 04-G4 - but not 01 or 02
AC Controller Channel Test #2 v19d4.zip

Are you able to duplicate this?

[AzGilrock]

Yes I see whacky stuff happening with that sequence but I want to rule out the overlap stuff first. Look at this screenshot. There are 12 Candy canes all mapped to the same 4 channels. BTW I'll be gone rest of the night.

[keithsw1111]

you should not have >model:0 if you want it on the same channel it should be @model:1 ... the *** means it is considered an error.

[keithsw1111]

The sequencing on hidden models is a bit confusing but not a problem per se

[keithsw1111]

So ... really cool bug ... at some time in the past you seem to have shifted effects to the point that some started at a time less than zero and finished at zero ... this was causing drama. If you need a win 64 version urgently let me know and I can send you one with the fixes.

[DoctorWiz]

There are actually 22 candy canes... 6 on 61, 6 on 62, 5 on 63, and 5 on 64. They are those 3' tall single color (red or green) candy canes sold at Walmart. They are wired such that every 4th one goes to a channel. I use them, along with a long string of pixels, as a fence around the edge of the property (my display is NOT a walk thru, and it discourages people from walking thru the yard, potentially tripping over stuff). That also gives me 21 upside-down arches or swags between them. If you have a better suggestion on how to model them, I'm listening...
Anyway, I'm about to make a copy of my show directory and bit-by-bit strip the setup and layout and previews down to the minimum and I'll let you know later today how that goes -- but--
The more I tinker with it, the more I can see it is a display problem with refreshing the grid. The underlying data is fine, and it does turn off the channels when/where I tell it to.
What's weird it is only affects about a 1/4 of the props, and always the same ones. But I don't (yet) understand why those ones and not others. The channels affected don't really have anything in common (or at least anything that isn't also in common with un-affected ones). Some of them overlap, most of them don't. Some of them start based on another one, some don't. They are not contiguous. I thought I might open the .xml file in Notepad++, Visual Studio, and/or XMLWiz and see if they were all clumped together in the file or maybe spot some other commonality. I'm also going to try re-arranging their display order and/or channel order.
Will keep you posted...

[DoctorWiz]

Keith, Gil...
I'm familiar with the shift effects command, but I have NOT done that. So the question is, how did they get that way (start before 0)? There may be an additional bug somewhere that caused that, so maybe that's something we should just all keep our eyes peeled for. I DID shorten the sequence from 30 seconds to 6, and there were some effects that extended past the 6 second mark. I'll see if I can duplicate a problem there.

HUGE thanks to all of you for a quick fix!! (Unlike the folks at LOR...)

Keith, can you clarify the proper way to put props on the same channel (overlap)? Should I just change the ">" at the beginning to a "@" and then the ":0" back to ":1"?

[DoctorWiz]

Yup! The start-before-zero problem was caused by shortening the sequence. I created a new sequence and initially could not duplicate the grid issue. Then I created some effects past the 6 second mark, then shortened the sequence to 6 seconds, and I was able to duplicate the grid problem.

[AzGilrock]

I could swear I remember there already being code that truncated anything less than 0.

So when you shortened the sequence what method did you use?

[DoctorWiz]

Steps: Create a new animated sequence (defaults to 30 seconds). Add some effects. Click on Settings -> Sequence Settings. Change the time in 'Sequence Duration' to something less than where the effect(s) are.

[AzGilrock]

Thanks I'll give that a try. Changing the Sequence Duration should not change any effect positions so not sure how they would end up less than 0.

[AzGilrock]

I agree if you shorten the sequence duration you can get effects that are on the right after the end but we allow that.

[DoctorWiz]

Seems to be a 'wrap around' situation. The same effects that got cut off past the new end time is what is getting erroneously placed in other locations in the grid. And on the same channels. Oh, and when trying to duplicate, note that I changed the end time such that some but not all of the effects (such as fades) crossed the new end line and so ended up getting split or truncated. Definitely an obscure problem and not likely to occur in the wild. Now that I know about it, I'll be sure to delete anything past the new end point before changing it. Not that I expect to be shortening sequences very often.

[AzGilrock]

Yeah from day one that grid was designed to handle effects extending past the end line because I didn't want people to have to worry about making effects end exactly at the end especially when some effects would change speed when you shorten them.

But you had other weird things going on in that sequence that didn't involve any effects past the end. One effect was spilling data into other channels and then I deleted that effect and then the effect before it started spilling data and so on.