Hello team. I think I have a beginner problem.
I usually always run animation on my leds board. But today while trying some stuff I have displayed fixed frames and I have noticed the first led if not of the right color (green or yellow or bright white)
I am using an esp32 dev board and ws2812
The strange thing is that if I do 2 fastledshow in a raw the wrong pixel disappears.
Does anybody had the same issue how did you solve it ?
Thank
Ps I never had that issue with esp8266
Thx
Perhaps it would be helpful to show the actual code
ESP32 support is fairly new and still has some glitches. Try out my branch at https://github.com/samguyer/FastLED
Oh, I just realized that you are hpwit on github!
@Sam_Guyer ahaha hello Sam. 
I am loosing my mind with that stuff lol.
Do two show() in a raw it works do two 500ms seconds apart and you have the glitch on the first one
I will try to see how ‘close’ to each other the two show need to be in order not to see the glitches maybe it will give me an idea of what is going on.
In the mean time I use FastLED.delay instead of delay.
As I mainly do animation that is not too much of an issue but still
I am trying to go to all the code to find what on earth it’s going on. Pretty interesting stuff
Ps I haven’t tried how your RMT implementation reacts.
Might be a “hardware” problem. Have you tried adding a resistor to limit the data line current? A capacitor across power to iron out the surges? A different LED strip?
@Kirill_Kolyshkin I have tried a resistor 330ohms, different led strips (from different batch) I will try try a capacitor accross the power.
I will also try a 74HCT235 with 100ohm like for the teensy not for level shifting but to be sure that there is real decoupling between the esp and the data line. Keep you posted
Sounds frustrating. Try the RMT implementation (note that is currently does not do parallel output). Or try calling show on core 0. Can you post a video of what you’re seeing?
@Sam_Guyer I will try that. For info capacitor nor the 74hct235 changed anything. Yesterday I have tried to debug it. It’s really strange and i can’t put my finger on it. I am losing my c++ over this lol. I will try with your rmt implentation. As the use of FastLED.delay instead of delay seems to make a nice workaround I will put it to rest for by the end of the week and come back to it with new eyes.
Btw I am thinking of implementing parallel out but using spi and fast shift register. So you could theorically have up to 32 lines (with an SPI speed of 80mhz) without too much timing issues. And using only 3 pins
For the noment I have only 74hc595 whose to speed is 5mhz to be able to rest I need at least 20mhz. So I will try (when I found one) with 74vhc595.
Keep you posted
This is totally a band-aid and a hack, but if its only the first pixel that is having this problem - just add a sacrificial pixel in the data cable of each output before you plug it into your display array, cover it with electrical tape if you want to not see it. I was having tons of artifacts and flicker in my one of the panels in my coat - especially when the matrix moved from one manufacturers batch of strips to another (I kind of cobbled together the matrix), but splicing in a single “good” pixel before the strips that were giving me trouble solved my problems. Then I just had to redo my mapping function so that my animations would skip over the extra pixels I had spliced in between some of the strips.
Its probably not the same problem you’re having, but the solution might work - at least as a patch until you find the real culprit!
@chad_steinglass Thank for the tip I was indeed thinking of doing that 
after just start at 1 instead of 0.
I have the same issue with different leds strips from different manufacturers.
I will normally receive 130m of 30led/m next week normally. I want to make a 15026 leds (5mx80cm) (using 13 pins in parallel output each pin 300leds) to try them out and then realize a 7548 panel (i’ve ordered couple more leds for spare parts when some leds die). can’t wait !!