starred/kvm

Fork 0

mirror of https://github.com/jetkvm/kvm.git synced 2026-03-02 22:58:00 -05:00

JetKVM unusable - Loading Video Stream #530

New issue

Closed

opened 2026-02-20 08:23:24 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-20 08:23:24 -05:00

Owner

Originally created by @mygrexit on GitHub (Feb 10, 2026).

Disclaimer

I have read and understood the disclaimer.

Application version

0.5.3

System version

0.2.7

Device model

JetKVM

Extension model

ATX Power Control

Remote device Hardware

No response

Remote device OS

No response

Bug description

This issue is still present on the latest firmware.

My setup:

App version: 0.5.3
System version: 0.2.7

This report is specifically about a subset of users for whom the problem is persistent and non-recoverable.

While some users report temporary relief through reboots, power-cycling, or browser-specific workarounds, for others (myself included) the video stream has never worked reliably or at all, regardless of mitigation attempts.

This is not a claim that no workaround ever helps anyone.

This issue is about the fact that:

for some users, the JetKVM never produces a working video stream
and no known workaround resolves it for this group

Including:

reboots
power-cycling
factory resets
firmware upgrades (including 0.5.3 / 0.2.7)
browser changes
LAN vs cloud access
following the Troubleshooting Guide in full

For affected users, the device remains unusable.

behavior

WebRTC signaling starts normally
ICE gathering completes
Peer connection may report “connected”
Video stream never appears, or shows a single frozen frame
Keyboard/mouse input may function, but without video this is not useful
Occurs both via local LAN access and cloud access

Impact

For affected users, the JetKVM cannot be relied upon for its primary purpose:

BIOS / boot-time access
headless system recovery
unattended or remote deployments
failure recovery scenarios

A remote KVM that cannot reliably deliver video is not operationally usable.

Several users report resorting to:

repeated SSH reboots
scheduled power-cycling
abandoning the device for critical use

These are mitigations, not solutions.

This issue has been reported continuously since January 2025, across:

App versions: 0.3.x → 0.5.3
System versions: 0.2.x → 0.2.7
Browsers: Firefox, Chrome, Brave, Safari, Edge
OS: macOS, Linux, Windows
Networks: LAN-only, cloud-only, NAT, CGNAT, VLANs
Hardware: cases where one JetKVM works and another does not under identical conditions

This strongly suggests that the problem is not limited to client configuration or browser policy, and may involve firmware, hardware, or specific runtime states the device cannot recover from.

support situation

The original issue (#84) was closed
Users are redirected to the Troubleshooting Guide
The Troubleshooting Guide links back to the closed issue
For the affected subset of users, all documented steps have already been exhausted

This leaves users with no clear next step, despite the issue persisting on current releases.

What would help clarify the situation:

At minimum:

Confirmation whether this persistent failure mode is known
Whether it is believed to be:
- a firmware defect
- a hardware-related issue affecting some units
- a known WebRTC edge case that cannot be fully mitigated
Guidance on whether affected users should:
- wait for further fixes
- downgrade firmware
- consider hardware replacement

The goal of this issue is not to re-open a “mega thread”, but to clearly document that for some users, the problem is permanent and unresolved on the latest versions.

Originally created by @mygrexit on GitHub (Feb 10, 2026). ### Disclaimer - [x] I have read and understood the disclaimer. ### Application version 0.5.3 ### System version 0.2.7 ### Device model JetKVM ### Extension model ATX Power Control ### Remote device Hardware _No response_ ### Remote device OS _No response_ ### Bug description This issue is still present on the **latest firmware**. My setup: - App version: **0.5.3** - System version: **0.2.7** This report is specifically about a subset of users for whom the problem is **persistent and non-recoverable**. While some users report temporary relief through reboots, power-cycling, or browser-specific workarounds, **for others (myself included) the video stream has never worked reliably or at all**, regardless of mitigation attempts. This is **not** a claim that *no* workaround ever helps *anyone*. This issue is about the fact that: - for **some users**, the JetKVM **never produces a working video stream** - and **no known workaround resolves it** for this group Including: - reboots - power-cycling - factory resets - firmware upgrades (including 0.5.3 / 0.2.7) - browser changes - LAN vs cloud access - following the Troubleshooting Guide in full For affected users, the device remains unusable. ### behavior - WebRTC signaling starts normally - ICE gathering completes - Peer connection may report “connected” - **Video stream never appears**, or shows a single frozen frame - Keyboard/mouse input may function, but **without video this is not useful** - Occurs both via **local LAN access and cloud access** ### Impact For affected users, the JetKVM cannot be relied upon for its primary purpose: - BIOS / boot-time access - headless system recovery - unattended or remote deployments - failure recovery scenarios A remote KVM that cannot reliably deliver video is **not operationally usable**. Several users report resorting to: - repeated SSH reboots - scheduled power-cycling - abandoning the device for critical use These are mitigations, not solutions. This issue has been reported continuously since **January 2025**, across: - App versions: 0.3.x → **0.5.3** - System versions: 0.2.x → **0.2.7** - Browsers: Firefox, Chrome, Brave, Safari, Edge - OS: macOS, Linux, Windows - Networks: LAN-only, cloud-only, NAT, CGNAT, VLANs - Hardware: cases where one JetKVM works and another does not under identical conditions This strongly suggests that the problem is **not limited to client configuration or browser policy**, and may involve firmware, hardware, or specific runtime states the device cannot recover from. ### support situation - The original issue (#84) was closed - Users are redirected to the Troubleshooting Guide - The Troubleshooting Guide links back to the closed issue - For the affected subset of users, all documented steps have already been exhausted This leaves users with **no clear next step**, despite the issue persisting on current releases. What would help clarify the situation: At minimum: 1. Confirmation whether this persistent failure mode is **known** 2. Whether it is believed to be: - a firmware defect - a hardware-related issue affecting some units - a known WebRTC edge case that cannot be fully mitigated 3. Guidance on whether affected users should: - wait for further fixes - downgrade firmware - consider hardware replacement The goal of this issue is not to re-open a “mega thread”, but to clearly document that **for some users, the problem is permanent and unresolved** on the latest versions.

deekerman closed this issue

2026-02-20 08:23:24 -05:00

deekerman commented

2026-02-20 08:23:25 -05:00

Author

Owner

@adamshiervani commented on GitHub (Feb 10, 2026):

Thanks for taking the time to writing that. Let's try to get to the bottom of this.

Send me the following:

Device information - Browser? OS? VPN? Hardware? Cables?
Diagnostics zip - Settings> Advanced > Troubleshooting mode > Download Diagnostics
Chrome WebRTC Dumps:
- While the JetKVM LAN IP is open chrome://webrtc-internals/. Expand the Create a WebRTC-Internals dump and send me the file.
- While the Cloud Dashboard tab is open chrome://webrtc-internals/. Expand the Create a WebRTC-Internals dump and send me the file.
Video Debugging Info - Settings > Video > Get Debugging Info
Browser Logs - In a tab that is stuck on Loading Video Stream, right click and click on Inspect. Click on Console and just copy all that information.

Try the following:

Disable HDMI Sleep Mode > Settings > Hardware > HDMI Sleep Mode and reboot
Test all the available EDID - Settings > Video > EDID

Once all that is done. Please try downgrading and let me know what works:

Downgrade the App to 0.4.8, while retaining the latest system version - Settings > Advanced > Developer Mode > Update to Specific Version
Upgrade to 0.5.3, but downgrade to system 0.2.5 - Settings > Advanced > Developer Mode > Update to Specific Version`

@adamshiervani commented on GitHub (Feb 10, 2026): Thanks for taking the time to writing that. Let's try to get to the bottom of this. Send me the following: - **Device information** - Browser? OS? VPN? Hardware? Cables? - **Diagnostics zip** - `Settings> Advanced > Troubleshooting mode > Download Diagnostics` - **Chrome WebRTC Dumps**: - While the JetKVM LAN IP is open `chrome://webrtc-internals/`. Expand the `Create a WebRTC-Internals dump` and send me the file. - While the Cloud Dashboard tab is open `chrome://webrtc-internals/`. Expand the `Create a WebRTC-Internals dump` and send me the file. - **Video Debugging Info** - `Settings > Video > Get Debugging Info` - **Browser Logs** - In a tab that is stuck on `Loading Video Stream`, right click and click on `Inspect`. Click on `Console` and just copy all that information. Try the following: - **Disable HDMI Sleep Mode** > `Settings > Hardware > HDMI Sleep Mode` and reboot - **Test all the available EDID** - `Settings > Video > EDID` Once all that is done. Please try downgrading and let me know what works: - **Downgrade the App to `0.4.8`**, while retaining the latest system version - `Settings > Advanced > Developer Mode > Update to Specific Version` - **Upgrade to `0.5.3`**, but downgrade to system `0.2.5` - Settings > Advanced > Developer Mode > Update to Specific Version`

deekerman commented

2026-02-20 08:23:25 -05:00

Author

Owner

@mygrexit commented on GitHub (Feb 10, 2026):

Sorry, I know this might seem a bit contradictory now.

After writing this issue, I've realized that the previous approach has led me to decide on implementing a different solution. I simply don't have the time and nerves for tedious debugging sessions, so I'm going back to reconnecting my PiKVMs. Unfortunately, how this has been handled so far has eroded my confidence.

@mygrexit commented on GitHub (Feb 10, 2026): Sorry, I know this might seem a bit contradictory now. After writing this issue, I've realized that the previous approach has led me to decide on implementing a different solution. I simply don't have the time and nerves for tedious debugging sessions, so I'm going back to reconnecting my PiKVMs. Unfortunately, how this has been handled so far has eroded my confidence.

deekerman commented

2026-02-20 08:23:25 -05:00

Author

Owner

@adamshiervani commented on GitHub (Feb 10, 2026):

All good! Nonetheless, thanks for taking the time reporting the issue. Best of luck!

@adamshiervani commented on GitHub (Feb 10, 2026): All good! Nonetheless, thanks for taking the time reporting the issue. Best of luck!