don't send invalid (black) frames to hyperion

[asturel]

It also causes massive cpu usage (e.g. without gui capture) since its in while (true) without sleep.

[TBSniller]

@asturel Do you think this is the right way to go? Two reasons:

• This problem only happens when no GUI capture is running and video capture on vtCapture was just started, so vt-Interface isn't initialized as no video is playing. So that we don't get an image is a problem more related to vtCapture, than to all capture libs.
• If we don't send something to framebuffer server for too long it's considered as a dead connection and so we get disconnected, don't we?

In my opinion this would be more a fix for the symptom then for the source of the problem. I think to fix the real problem, we should consider to add a sleep of few ms when vtCapture_init is not 0

[asturel]

Why should we send invalid frames at the first place? If I dont have gui capture enabled, then it keeps sending invalid (black) frames until I don't have video capture (also this kills idle effect IIRC) ? Even If You add some sleep (how much? you need to define different waits for different vt capture errors then..? otherwise you miss important frames or just end up using many resources again), it consumes valuable resources, specially hyperion processing.

If we don't send something to framebuffer server for too long it's considered as a dead connection and so we get disconnected, don't we?

Yepp, but it have re-try logic which reconnects at every 100ms ( or 1000ms?), still better (consumes 1/100 resources) than hammering hyperion.ng with invalid frames.