Docs: Update lessons_learned.md with flickering problem diagnosis and proposed solution

This commit is contained in:
Tobias J. Endres 2025-08-15 22:25:18 +02:00
parent 9c98604e12
commit 1fee3e518f

View File

@ -148,4 +148,16 @@ This configuration is still primarily handled **within the WLED device itself**.
* Confirmed that WLED is listening on UDP port `21324` for Realtime data (from `/json/cfg` `if.sync.port0`).
* After rebuilding and re-running `wled_test`, the LEDs successfully displayed the full color sequence (Red, Green, Blue, White, Black) as expected.
**Conclusion:** The issue was a mismatch between the sent color order (RGB) and the WLED's expected color order (RGB, confirmed by configuration). The `wled_test` program now correctly demonstrates full color control.
**Conclusion:** The issue was a mismatch between the sent color order (RGB) and the WLED's expected color order (RGB, confirmed by configuration). The `wled_test` program now correctly demonstrates full color control.
### Current Problem: Flickering with Static Screen
**Observation:** When running `Hyperion_Grabber_Wayland_QT`, some LEDs change color even when the screen is visually static, leading to flickering.
**Diagnosis:**
* Analysis of `output.log` revealed that the `scaledImage` (the input to `WledClient`) is *not* perfectly static, even when the screen appears still. The `WaylandGrabber` or underlying system introduces subtle pixel variations, causing the image checksum to constantly change.
* Our initial image difference threshold (`_changeThreshold_m = 100`) was too low, allowing these minor, visually imperceptible changes to trigger new frames to be sent to WLED.
**Proposed Solution:**
* Increase the `_changeThreshold_m` significantly to filter out the noise from the screen capture. This will prevent sending new frames to WLED unless there's a visually significant change on the screen.