Docs: Update lessons_learned.md with flickering problem diagnosis and proposed solution
This commit is contained in:
parent
9c98604e12
commit
1fee3e518f
@ -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.
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user