TESMart Plugin Update Lag #743

New issue

Closed

opened 2026-02-20 14:05:22 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-20 14:05:22 -05:00

Owner

Originally created by @bbeaudoin on GitHub (Sep 23, 2023).

Originally assigned to: @mdevaev on GitHub.

Describe the bug
The TESMart plugin at kvmd/plugins/ugpio/tesmart.py has update lag for the active port indicator. This is possibly related to both the switch_delay (1s) and state_poll (10s), the switch delay being some voodoo I introduced when I didn't understand how the response related to the inputs and polling interval possibly leading to a backlog of state changes over time.

Rebooting PiKVM immediately reflects the current selected port and new changes will be reflected within about 20s (async poll of the switch plus an unknown period between async Web UI updates), it's unknown why the polling seems to accumulate delays after some number of days or weeks of uptime without a connected user.

To Reproduce
Select a TESMart switch port via the GPIO menu and time how long it takes for the LED to change. For maximum effect, make multiple changes (such as 7 to 8 to 9, then back to 8 and 7 and see that the display updates the indicator approximately every 20 seconds in the order in which the selections were made.

Expected behavior
When using the GPIO menu to select a report, an immediate UI refresh might be expected. The async polling nature can possibly be improved as well to avoid accumulation of delay intervals and/or number of updates leading to an apparent lack of refresh.

Screenshots

Desktop (please complete the following information):
Not relevant, identical behavior on all platforms and systems, somewhat alleviated by rebooting PiKVM.

PiKVM info:
PiKVM v4 Plus
[root@pikvm ~]# pacman -Q|grep kvmd
kvmd 3.256-1
kvmd-fan 0.26-1
kvmd-oled 0.25-1
kvmd-platform-v4plus-hdmi-rpi4 3.256-1
kvmd-webterm 0.43-1
[root@pikvm ~]# pacman -W|grep ustreamer
pacman: invalid option -- 'W'
[root@pikvm ~]# pacman -Q|grep ustreamer
ustreamer 5.42-1
[root@pikvm ~]# uname -a
Linux pikvm 5.15.92-1-rpi-ARCH #2 SMP Sat Sep 9 00:58:18 MSK 2023 armv7l GNU/Linux
[root@pikvm ~]#

Additional context
Last year I snooped on the protocol traffic and saw when a consistent TCP/IP connection was established, the KVM reports, in real time, changes to the port selection. This is similar to using the serial connection with EZCoo. Bidirectional communication is possible, the "responses" aren't actually direct responses to commands, they are more like broadcast traffic to all actively connected clients.

The TESMart communicates to the user in two ways. One is a notification of change, one is an async update at random intervals of the current setting. When first experimenting and documenting, the async updates could be confusing leading me to add a 1s delay to the communication thinking this was caused by connecting and disconnecting in rapid succession.

I don't know whether it's in the cards to abandon polling for a persistent connection (or a connection that persists as long as a user is actively connected to PiKVM). Maintaining an active connection may be less costly than periodic polling.

It's not known if polling continues when there are no users and if this is leading to an accumulation of states that are replayed once a user connects or if something else is contributing to the update delays. At present my Python skills have degraded to the point where I can't easily determine the source of delays other users are reporting, I can only confirm the delays and speculate based on my knowledge of the TESMart through some level of understanding through packet captures.

Originally created by @bbeaudoin on GitHub (Sep 23, 2023). Originally assigned to: @mdevaev on GitHub. **Describe the bug** The TESMart plugin at kvmd/plugins/ugpio/tesmart.py has update lag for the active port indicator. This is possibly related to both the `switch_delay` (1s) and `state_poll` (10s), the switch delay being some voodoo I introduced when I didn't understand how the response related to the inputs and polling interval possibly leading to a backlog of state changes over time. Rebooting PiKVM immediately reflects the current selected port and new changes will be reflected within about 20s (async poll of the switch plus an unknown period between async Web UI updates), it's unknown why the polling seems to accumulate delays after some number of days or weeks of uptime without a connected user. **To Reproduce** Select a TESMart switch port via the GPIO menu and time how long it takes for the LED to change. For maximum effect, make multiple changes (such as 7 to 8 to 9, then back to 8 and 7 and see that the display updates the indicator approximately every 20 seconds in the order in which the selections were made. **Expected behavior** When using the GPIO menu to select a report, an immediate UI refresh might be expected. The async polling nature can possibly be improved as well to avoid accumulation of delay intervals and/or number of updates leading to an apparent lack of refresh. **Screenshots** ![](https://cdn.discordapp.com/attachments/896216359963332628/1155221229557526730/image.png) ![](https://cdn.discordapp.com/attachments/896216359963332628/1155223544746225675/image.png) **Desktop (please complete the following information):** Not relevant, identical behavior on all platforms and systems, somewhat alleviated by rebooting PiKVM. **PiKVM info:** PiKVM v4 Plus [root@pikvm ~]# pacman -Q|grep kvmd kvmd 3.256-1 kvmd-fan 0.26-1 kvmd-oled 0.25-1 kvmd-platform-v4plus-hdmi-rpi4 3.256-1 kvmd-webterm 0.43-1 [root@pikvm ~]# pacman -W|grep ustreamer pacman: invalid option -- 'W' [root@pikvm ~]# pacman -Q|grep ustreamer ustreamer 5.42-1 [root@pikvm ~]# uname -a Linux pikvm 5.15.92-1-rpi-ARCH #2 SMP Sat Sep 9 00:58:18 MSK 2023 armv7l GNU/Linux [root@pikvm ~]# **Additional context** Last year I snooped on the protocol traffic and saw when a consistent TCP/IP connection was established, the KVM reports, in real time, changes to the port selection. This is similar to using the serial connection with EZCoo. Bidirectional communication is possible, the "responses" aren't actually direct responses to commands, they are more like broadcast traffic to all actively connected clients. The TESMart communicates to the user in two ways. One is a notification of change, one is an async update at random intervals of the current setting. When first experimenting and documenting, the async updates could be confusing leading me to add a 1s delay to the communication thinking this was caused by connecting and disconnecting in rapid succession. I don't know whether it's in the cards to abandon polling for a persistent connection (or a connection that persists as long as a user is actively connected to PiKVM). Maintaining an active connection may be less costly than periodic polling. It's not known if polling continues when there are no users and if this is leading to an accumulation of states that are replayed once a user connects or if something else is contributing to the update delays. At present my Python skills have degraded to the point where I can't easily determine the source of delays other users are reporting, I can only confirm the delays and speculate based on my knowledge of the TESMart through some level of understanding through packet captures.

deekerman

2026-02-20 14:05:22 -05:00

closed this issue
added the
type:bug

resolution:fixed
labels

deekerman commented

2026-02-20 14:05:24 -05:00

Author

Owner

@arch1mede commented on GitHub (Sep 24, 2023):

(Hope this is helpful) Just to add to this, a user within the channel was able to clear the lag by restarting kvmd

@arch1mede commented on GitHub (Sep 24, 2023): (Hope this is helpful) Just to add to this, a user within the channel was able to clear the lag by restarting kvmd

deekerman commented

2026-02-20 14:05:25 -05:00

Author

Owner

@bbeaudoin commented on GitHub (Sep 24, 2023):

Unfortunately not helpful, restarted kvmd yesterday to clear whatever was preventing the source indicator from updating (by rebooting PiKVM). 24 hours later, the issue unfortunately returned.

PiKVM Source Selection Bug Video

Sure enough, restarting PiKVM does set things right again but ensuring one is rebooting the correct system based on the selection can get a bit risky if one doesn't know the indicator isn't updating at all. I second guessed hard powering system #9 myself while recording but I also had confirmed the port using a command line script.

@bbeaudoin commented on GitHub (Sep 24, 2023): Unfortunately not helpful, restarted kvmd yesterday to clear whatever was preventing the source indicator from updating (by rebooting PiKVM). 24 hours later, the issue unfortunately returned. [PiKVM Source Selection Bug Video](https://cdn.discordapp.com/attachments/363821564984295427/1155680054387408926/PiKVM_Source_Indicator_Bug.mp4) Sure enough, restarting PiKVM does set things right again but ensuring one is rebooting the correct system based on the selection can get a bit risky if one doesn't know the indicator isn't updating at all. I second guessed hard powering system #9 myself while recording but I also had confirmed the port using a command line script.

deekerman commented

2026-02-20 14:05:25 -05:00

Author

Owner

@mdevaev commented on GitHub (Oct 26, 2023):

Fixed

@mdevaev commented on GitHub (Oct 26, 2023): Fixed