DDA grabber: Set a 500ms timeout when waiting for a new frame

[davidsansome]

Summary

Previously the DDA grabber would wait forever (set an INFINITE timeout) for a new frame. The API only delivers a new frame to the application if some part of the display has changed, so if nothing on the display was changing then the AcquireNextFrame call would block for a long time, Hyperion wouldn't deliver new data to the LEDs, and WLED would shut off.

This change sets a 500ms timeout, which ensures the grabber returns a new image to Hyperion at least every 500ms even if nothing on the display has changed.

What kind of change does this PR introduce? (check at least one)

• [X] Bugfix
• [ ] Feature
• [ ] Code style update
• [ ] Refactor
• [ ] Docs
• [ ] Build-related changes
• [ ] Other, please describe:

If changing the UI of web configuration, please provide the before/after screenshot:

Does this PR introduce a breaking change? (check one)

• [ ] Yes
• [X] No

If yes, please describe the impact and migration path for existing setups:

The PR fulfills these requirements:

• [ ] When resolving a specific issue, it's referenced in the PR's body (e.g. Fixes: #xxx[,#xxx], where "xxx" is the issue number)

If adding a new feature, the PR's description includes:

• [ ] A convincing reason for adding this feature
• [ ] Related documents have been updated (docs/docs/en)
• [ ] Related tests have been updated

PLEASE DON'T FORGET TO ADD YOUR CHANGES TO CHANGELOG.MD

• [ ] Yes, CHANGELOG.md is also updated

To avoid wasting your time, it's best to open a feature request issue first and wait for approval before working on it.

Other information:

[Lord-Grey]

Have you seen that WLED has shut off the lights when there is no update in a given timeframe? I though in live streaming mode , which we are using, this would not happen. … but I might remember incorrectly. In which WLED version did it occur?

I get that the infinite blocking might cause certain issues, nevertheless, if an LED device is not stable showing an update or a longer period of time, the better approach would be to set a rewrite time at the device. That would avoid to go through full processing.

Therefore, I would ilke to understand, if the rationale is a „misbehavior“ at the LED side that is fixed at the grabber or if the infinite wait causes problems during frame capturing.

Thank you!

[davidsansome]

Ah sorry for the late reply @Lord-Grey!

Yep I'm definitely seeing WLED shut off the lights if there's no update. I'm using version 0.15.0-b2. I agree it would be better to have a rewrite time at the device, but I wasn't sure if blocking the grabber thread indefinitely would cause other issues as well.