UDP on main segment only.#2601
Conversation
| function setLor(i) { | ||
| var obj = {"lor": i}; | ||
| // allow canceling live mode (if sender crashes) | ||
| if (i===0 && lastinfo.live && ["","Hyperion","UDP"].includes(lastinfo.lm)) { obj.live = false; obj.v = true; } |
There was a problem hiding this comment.
I don't think this is a good idea, since setLor(0) is supposed to return to live data, not cancel it. It would likely be preferable to exit indefinite (timeout == 65000) live mode on override (1 or 2), as turning off lor will not refresh the LEDs anyways.
There was a problem hiding this comment.
I know. I mentioned this on Discord. This "hack" allowed me to test cancelling live mode.
If you can figure out where to put "live":false and not obstruct UI I am happy with it.
| realtimeLock(realtimeTimeoutMs, REALTIME_MODE_DDP); | ||
|
|
||
| if (!realtimeOverride) { | ||
| if (!realtimeOverride || (realtimeMode && useMainSegmentOnly)) { |
There was a problem hiding this comment.
I think override should override Live mode if on main seg only too. Otherwise override never functions if set to main segment only.
There was a problem hiding this comment.
There is no "real" need for override in mainseg only if you can cancel live. You can argue that a user may want displaying effects instead of live data on mainseg while not cancelling live streaming (temporary).
This will need a new UI element (perhaps a star in the segment?)
There was a problem hiding this comment.
This just gave me an idea!
| udpn["recv"] = receiveNotifications; | ||
|
|
||
| root[F("lor")] = realtimeOverride; | ||
| root[F("lor")] = realtimeOverride || (realtimeMode && useMainSegmentOnly); |
There was a problem hiding this comment.
This one should stay of course until UI is adapted to not show the live popup in main seg mode.
| root[F("name")] = serverDescription; | ||
| root[F("udpport")] = udpPort; | ||
| root["live"] = (bool)realtimeMode; | ||
| root[F("mso")] = useMainSegmentOnly; // using main segment only for live |
There was a problem hiding this comment.
Better to do root[F("liveseg")] = useMainSegmentOnly ? strip.getMainSegmentId() : -1;, since that gives more flexibility for us to potentially decouple it from main segment in the future, and the API user saves a step because they do not need to look up state.mainseg.
There was a problem hiding this comment.
Ok. We will need to inform Lord-Grey (Hyperion) of the change.
There was a problem hiding this comment.
What does it mean? The LED Grouping Thread got closed. Does it mean Grouping will be possible or is it dead? I currently have 144LED/m stripes on 65“ (636LEDs) and have to use tmp2net. The Problem is, i got a max of 38fps. I hoped of grouping to reach 60fps. I could solder a second wled with two instances, but i hope for the grouping
There was a problem hiding this comment.
Download and see. 😄
There was a problem hiding this comment.
i dont get it... i flashed the latest v13.2 "Toki" release, activated "main segment only" and nothing happend... still 38 fps... the fps counter in hyperHDR showed me a way higher transferrate (2-3x more fps), but the LEDs just get controlled by 38fps from the ESP32. I hoped that a grouping will increase the rate - but maybe i have to solder a second ESP32 for two instances.... or do you have a nother hint, how i can get more FPS??? i tried to split my 636 LEDs on two different pins - but FPS are still the same. It just increase, when i decrease the amount of LEDs.... my goal are 60FPS with 636LEDs... Ideas? (THX btw. for your nice & hard work!)
btw. What did "main segment only" do?
There was a problem hiding this comment.
@dimitrij2k Try increasing the Target refresh rate in the bottom of LED settings to 120. What grouping are you using, aka how many LEDs are transmitted?
There was a problem hiding this comment.
Hey Aircookie, i already played with the Target refreshrate, but it dont help. The problem is not only the live streaming with the fps. Even the "Effects" in WLED are running with only 38fps.
My Setup: SK6812 RGBW LEDs are running with an ESP32-ETH01 (Cable) to a Asus AX86U Router.
Im using HyperHDR on my LG WebOS (installed on TV). As protocol only tmp2net is working correctly at this moment (because of the LED count). I use as Max PacketSize 642 (for the LED Count + 6). Peak Performance is 38fps.
When i split my LEDs on two Pins (pin 2 = 315 LEDs, pin 3 = 321 LEDs) the 38fps are the same. When i reduce the LED Count in WLED to 400LEDs, i get 60fps... below 400LEDs the fps rise, over 400LEDs the fps decrease.
In HyperHDR i tried a direct LED mapping and Grouping of 10LEDs to 21 Zones (Top/Bottom) and 12 Zones (Left/Right)... but i never reach more then 38fps with my LED Count.
Thanks for your support!
There was a problem hiding this comment.
Your packet size is too small. And even the largest possible will not hold enough data for all LEDs. It will be fragmented.
At least as I see it from the description.
| jsonTransitionOnce = true; | ||
| liveEnabled = true; // triggers realtimeLock() below | ||
| realtimeLock(65000); | ||
| } else { |
There was a problem hiding this comment.
I think I like this in principle, but I think there should be more ways to exit indefinite live mode, e.g. turning off and on master power or setting an effect on mainseg if in mainseg only mode. Will think about it a little.
Fix for missing udp.cpp
Make override work in mainseg mode Move unfreeze on turn on from UI to JSON parser Fix mainseg not unfreezing on timeout
3 participants
Allow playing UDP live (Hyperion) or realtime (DDP, E1.31, ArtNet) data on main segment only (instead of whole strip).