LEDs do not turn off when TV is off (ESP32 always powered)

[Evan7121]

Is your feature request related to a problem? Please describe

When I turn off my TV, the LEDs don't turn off automatically.

Describe the solution you would like

The DDP protocol should automatically disable itself when Hyperion stops sending data so that the LEDs turn off.

Describe alternatives you've considered

Buy a smart plug

Additional context
None

[softhack007]

The root cause of the problem could be the way that the "live": true json command is implemented: When entering realtime mode by json API command, the timeout is "infinite" so the controling device has to explicitly command "end realtime".

WLED/wled00/json.cpp

Lines 451 to 459 in f830ea4

	if (root.containsKey("live")) {
	if (root["live"].as<bool>()) {
	jsonTransitionOnce = true;
	strip.setTransition(0);
	realtimeLock(65000);
	} else {
	exitRealtime();
	}
	}

65000 is a magic number that means "infinite".
Actually it might be better to replace this with realtimetimeout, possibly guarded by a user option.

The rabbit has done some analysis (#5370 (comment)) of protocols we support, and the result was:

• no protocol demands an infinite stay in realtime mode
• using the json API is not necessary any more before receiving live leds -- if you select "Receive UDP realtime" in sync settings, then WLED will automatically switch to realtime mode when data arrives, and fall back to local effects when the stream ends.
• "infinite timeout" was an implementation decision but nobody knows any more why it was implemented that way.

[netmindz]

Do we know if Hyperion send any json calls or just DDP?

[CodingGhost]

I have the same problem. I guess removing the infinite timeout and using the configured timeout would fix it.

[DedeHai]

I guess removing the infinite timeout and using the configured timeout would fix it.

the problem (as so often) with that is: will it break something else that does rely on it being infinite.

[CodingGhost]

one possible way to rule that out would be to make it configurable and set the default to infinite maybe?

[blazoncek]

make it configurable

There is already an option for that albeti hidden in JAON API.

Hyperion (or any other similar host) already needs to send JSON API for start of Live data. This "start" command is by the definition infinite "start", to end it just send JSON API for stop.

If the host doesn't send "start" command any Live data is considered temporary and will automatically terminate 2.5 seconds after last packet is received.

[discordianfish]

I've got the same problem since I run hyperion on my lg tv and sometime turning the tv off doesn't give hyperion time to gracefully stop the ddp connections. Even if this 'bug' would be gone, some sort of timeout to account for crashes, hard server shutdown etc would be good IMO.

@blazoncek What do you mean by its already configurable? Could hyperion use something else than 'start' that would not set the timeout to infinite?

[blazoncek]

The OP talks about DDP which is not what Hyperion does AFAIK. Hyperion uses raw UDP (or at least it used to while I participated in WLED development). However, that does not affect the issue at hand.

The issue is "start live data" was sent to WLED but no "stop live data" is ever sent to it when streaming data actually terminates.

You can recover by (manually) sending appropriate JSON API command to WLED. The API command (as of this writing) is {"live":false} as described in KB.

Using curl: curl --header "Content-Type: application/json" --request POST --data '{"live":false}' http://wled.local/json

Could hyperion use something else than 'start' that would not set the timeout to infinite?

Hyperion would not need to send "start" if every update would be within 2.5s. However Hyperion may not send every update within 2.5s and will only send data on "as needed" basis. Hence it requires "start" command.