Hello! i'm quite new in this group and i've read alot,

@X-WL1 hello why did you comment the code in the. NormalParseU7 function ?
NormalParseU8 is not need as you ah e only 8 strips and not 9.
You could simplify you code
Your loop in the NormalParseUx functions could be replaced by a
memcpy(&leds[xnum_led_per_strip], &packet->data[0],3num_led_per_strip)

@X-WL1 the example you should used is this one https://github.com/hpwit/artnet/blob/master/examples/exampleArtnet/exampleArtnet.ino
The other ones are not compatible with the new version of the library. I should erase those

@Yves_BAZIN I know, decided not yet to simplify, because I ran into a problem.

@X-WL1 oki indeed first rule of coding make it work and then optimize;)

@Yves_BAZIN I do not like the version with synchronization, since I just cause the pixels to be displayed after a certain time. Can the problem be in this? the second core encounters changing values.

@X-WL1 the pixels are displayed after receiving a full frame.
I have just made a slight change to my program you cannot encounter changes on the second core and it cannot provoque 0 division error. But as I said earlier the artnetwifineopixel sketch is not compatible with my library

@Yves_BAZIN I do not use your branch at all) and the error of division is not the main thing. in my version of the @Sam_Guyer code. sorry for the confusion)

@X-WL1 ah oki I thought you you has a divided by zero using my branch of artnet ;).
For you issue that is strange indeed
Try this
Comment lines 638,639,640 and 658
Line 659 add
userTaskHandle=0;

@Yves_BAZIN OK! Have you tried to compile and use my code?

@X-WL1 I can compile it. To use it I don’t have your led set up :wink:

@Yves_BAZIN this is not necessary) there everything is clear on the log in the Serial Port.

Oki i will set up a small set up for glediator to send artnet packet

@Yves_BAZIN you will have to send packets to a fixed ip.broadcast yet does not work. Thanks)

@X-WL1 I go grocery shopping and I have a look at that. I am sure will find why

@X-WL1 I have just tried your code with the latest version of Sam’s code without sending any packets and I have an FPS of 25/26
So it’s not the display which is slow.

@Yves_BAZIN your code is good for certain cases, but if packet packets are delayed, it will wait for the full frame, I do not need the maximum speed to work with strobe and others …

@Yves_BAZIN this correction led to the appearance of artifacts and the conclusion to the diodes still stopped. but now the function FastLEDShowESP32 () does not take 200ms and even managed to reach more than 25 fps. however, the picture is not updated (((

@X-WL1 yes indeed but
If you you do not do that you will have frame that are composed of universes made of different frames.
And a full frame it’s 1/25 second
And I have tested it with 6000pixels and it’s pretty smooth.
If you try it you will see no issue unless you have network issue.
Plus to cope with that I have implemented buffering
In the artnet.begin the last parameter is the size of the buffer.
The program will store the frames received.
I used this to implement a function to store artnet frames on a sd card and it’s pretty good with 0 frame lost over 2000 pixels
But for a strange reason after a while the FPS of you program goes from 25 FPS to 5 FPS
.

@Yves_BAZIN this is wifi! problems with the network are inevitable :)) for this it is better to let the beat frame. I will use several such devices that are not synchronized, so this is not critical. regarding the fall of fps: as I understood, the task to send data to diodes and the code waits for 200ms (638 lines), hence 5 fps.

@X-WL1 yes indeed checking the time the fastened show takes it’s performer drops from 5-6 ms to 200ms.
That is strange