Playlist doesn't stop on ir remote FX command

[Niorix]

What happened?

I have 38 keys IR with default config and playlist.
If the playlist has begun, it does not stop when another effect is called using the remote control.
I try Rainbow key as test, but Rainbow is canceled by the next effect of the playlist after some timeout.

To Reproduce Bug

create at least 1 preset and one playlist.
Select playlist as current effect.
Press ir remote button with next config:
"0xXXXXXX": {
"label": "Fire",
"pos": "6x4",
"cmnt": "Fire 2012",
"cmd": "FX=66&FP=35"
}

Expected Behavior

IR remote button stopped playlist and set selected effect.

Install Method

Binary from WLED.me

What version of WLED?

WLED 0.15.0-rc1 (build 2411250)

Which microcontroller/board are you seeing the problem on?

ESP8266, ESP32

Relevant log/trace output

No response

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[blazoncek]

Please use JSON API and the playlist will be unloaded.

The HTTP API behaviour is such by design.

  // set effect parameters
  if (updateVal(req.c_str(), "FX=", &effectIn, 0, strip.getModeCount()-1)) {
    if (request != nullptr) unloadPlaylist(); // unload playlist if changing FX using web request
    fxModeChanged = true;
  }

[Niorix]

Thanks for reply!

1. Using HTTP API (curl "http://xxx.xxx.xxx.xxx/win&FX=66&FP=35") playlist will be unloaded in WLED 0.15.0-rc1 (build 2411250).
2. Using HTTP API in ir_remote.json ("cmd": "FX=66&FP=35") playlist will not be unloaded in WLED 0.15.0-rc1 (build 2411250).
3. Using preset in ir_remote.json ("cmd": "!presetFallback","PL": 1) playlist will be unloaded in WLED 0.15.0-rc1 (build 2411250).
4. Effect call in ir_remote.json ("cmd": "!presetFallback","FX": 66) not work, and call preset whith id=1 if exist.
   How i may unload playlist using ir_remote.json without call any preset, such as third example?

[blazoncek]

Use JSON API.

[Niorix]

I understand you. I used {"seg": {"fx": 66}}. It's worked.

[blazoncek]

@willmmiles you may need to revisit HTTP API rewrite to see if original behaviour still exists.

[willmmiles]

We didn't merge the rewrite , only the null pointer check to fix the crash case. There were still a number of other issues with it I haven't had a chance to address yet.