Deleting segments is not handled properly

[DedeHai]

What happened?

When having multiple segments, deleting one of them results in broken segment configuration with one exception: if it is the last segment that is deleted.

To Reproduce Bug

I tested like this on a 16x16 matrix, setting-up 3 overlapping segments:

• Segment 0: initial segment is 16x16
• Segment 1: overlapping segment 8x16 (start at x=0)
• Segment 2: overlapping segment 8x16 (start at x=8)

setup any FX you like, I used "Black Hole" on all three segments
delete the middle segment -> the last segment gets broken and has to be deleted before it can work again

Expected Behavior

deleting a segment should not mess up other segments, it should be properly handled.

Install Method

Binary from WLED.me

What version of WLED?

Not working on 14.4 and 15 B7

Which microcontroller/board are you seeing the problem on?

ESP32-C3

Relevant log/trace output

No response

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[softhack007]

This might be a case of "it was always like this", however would be good to understand the root cause before releasing 0.15.0-RC1

• 0.15.0-rc1 #4287

[DedeHai]

I stumbled upon this when working on the new memory management for the particle system. When deleting the middle segment, there is a particle memory request (which is done when initializing a new FX i.e. call==0) with a segment of nonsensical size of x=0, y=16 which I confirmed is created by deserializeSegment calling the segment setUp() function. So the root cause may be even coming from the UI or incorrect handling of the UI decoding.

[netmindz]

Sounds like not a blocker for rc1 then

[blazoncek]

FYI segments are not deleted from memory when user removes them form UI (or using API). Instead they are deactivated.
This behaviour is the same as it was since 0.10 (stop becomes 0), the difference is that since 0.14 segments are stored in vector and not in fixed size array. This is also where isActive() method comes from.
If a user later re-activates such segment (using API) no memory intensive operations happen.

Removing segment when it is deactivated is possible, just remove it from vector and you are done. Be aware that this will trigger copying/moving active segments in memory (from one vector to a new one). Pruning/purging is done if more than half of segments are deactivated to release some memory.

One possible way to work around the issue may be to manually condense vector by overwriting deactivated segments with still active segments (using move constructor) and then prune remaining inactive segments.

As for non-working third segment from example above, only debugging can show what's happening with it. I have the feeling that root issue lies in UI rather than segments themselves. But I may be wrong.

[DedeHai]

FYI: this is fixed in 0.16

[softhack007]

maintainers: I think this is still a problem, at least if the "delete preset" call is overlapping with another ongoing preset modification - for example when first updating a preset from the UI (keep "overwrite with state" disabled), and then quickly after that delete any other preset.

WLED/wled00/presets.cpp

Lines 280 to 285 in 53d6c4b

	void deletePreset(byte index) {
	StaticJsonDocument<24> empty;
	writeObjectToFileUsingId(getPresetsFileName(), index, &empty);
	presetsModifiedTime = toki.second(); //unix time
	updateFSInfo();
	}

WLED/wled00/json.cpp

Lines 499 to 501 in 53d6c4b

	ps = root[F("pdel")]; //deletion
	if (ps > 0 && ps < 251) deletePreset(ps);

[softhack007]

@coderabbitai please check if the scenario described in this report - presets or segments corruption due to parallel changes from several tasks - is still possible in the main branch. Consider that there are two possible paths - depending on UI options used when creating or updating a preset. The expected behaviour should be that all file writes to presets.json are serialized asynchronously via the main loopTask. Please also verify if the existing JSON buffer locking mechanism can effectively prevent presets corruption due to parallel writing.

[softhack007]

oopsie - mixed things up - this issue is about deleting segments, not about the preset deletion bug 😅