You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So I have HyperHDR up and working great. I just have one problem. The lights don't turn off without manual intervention on the web page.
I have an always-on Roku Ultra as the source. It goes through an HDMI switch, to an HDMI splitter and on to the capture board.
I tried automatic calibration but that did not work, so I tried manual calibration. I set the Roku to go to an all-black screensaver after 5 minutes. Turned off the TV and waited. Backlight stayed on. Still on 30 minutes later. So I go into the HyperHDR web page to check the Live feed on the LED Visualization page. Lights go out instantly. It's as if opening the page reminded the system to check if the signal had been lost.
So I looked at the logs and no, the instant the source goes black the system detects it and switched to source "priority channel 254". I had thought a loss of signal would force it to idle state and thus the background effect (mine is set to black (0,0,0) of Priority channel 255, but no.
Any suggestions? I have reproduced this several times. Not sure if I have something misconfigured or what.
Hi
What I can say? Automatic detection definately works fine on many system and it's recommended over the manual detection (you MUST be sure about colors thresholds in manual calibration: "black" in capturing in not always real black RGB and only a part of the screen is tested compared to the automatic detection).
Most common mistake for automatic detection is to calibrate the signal for the video source and then to change the capturing resolution or capturing format or the framerate. In such situation the calibration must be done again. But there is a warning in the logs about that. So I recommend you to test again the automatic detection, try to trigger no-signal on your system and to observe the logs: without them captured while this happens cannot help more.
I just tried it with automatic detection and am having the same issue. The logs in each case show that the system is detecting the loss of signal. The problem is that until I open the LED Visualization window on the web app, the LEDs are still on.
Here is a chunk of the logs:
:20:54.780Z [V4L2:EZCAP U3 CAPTU] Video FPS: 59.97, av. delay: 6ms, good: 3598, bad: 0 (60.01,15)
2022-03-26T14:21:12.172Z [WEBSOCKET] (JsonAPI.cpp:1300) log streaming activated for client ::ffff:192.168.2.51
:20:54.780Z [V4L2:EZCAP U3 CAPTU] Video FPS: 59.97, av. delay: 6ms, good: 3598, bad: 0 (60.01,15)
2022-03-26T14:21:12.172Z [WEBSOCKET] (JsonAPI.cpp:1300) log streaming activated for client ::ffff:192.168.2.51
2022-03-26T14:21:33.884Z [SIGNAL_AUTO] No signal detected. The cognition model's probability: 100%
2022-03-26T14:21:38.900Z [SIGNAL_AUTO] THE SIGNAL IS LOST
2022-03-26T14:21:42.527Z [MUXER0] Priority 230 is now inactive
2022-03-26T14:21:42.528Z [MUXER0] Set visible priority to 254
2022-03-26T14:21:42.528Z [HYPERHDR0] New priority[254], previous [230]
2022-03-26T14:21:42.529Z [IMAGETOLED0] (ImageProcessor.cpp:180) set hard led mapping to multicolor_mean
2022-03-26T14:21:42.529Z [V4L2:EZCAP U3 CAPTU] The video control requested for the grabber restart due to signal lost, but it's caused by signal detection. No restart.
This is the same behavior seen with manual detection.
OK, also have got logs even longer that shows what is happening. Without background effects:
2022-03-26T14:40:31.609Z [SIGNAL_AUTO] THE SIGNAL IS LOST
2022-03-26T14:40:32.979Z [MUXER0] Priority 240 is now inactive
2022-03-26T14:40:32.979Z [MUXER0] Set visible priority to 255
2022-03-26T14:40:32.979Z [HYPERHDR0] New priority[255], previous [240]
2022-03-26T14:40:32.979Z [HYPERHDR0] No source left -> switch LED-Device off
2022-03-26T14:40:32.980Z [SMOOTHING0] Clearing queued colors before: disabling
2022-03-26T14:40:32.980Z [SMOOTHING0] Smoothing queue is cleared
2022-03-26T14:40:32.980Z [LEDDEVICE_FILE] (LedDevice.cpp:135) Disable device
2022-03-26T14:40:32.981Z [LEDDEVICE_FILE] (LedDevice.cpp:200) Stopping timer
2022-03-26T14:40:32.982Z [LEDDEVICE_FILE] (LedDevice.cpp:335) Switch off
2022-03-26T14:40:32.982Z [LEDDEVICE_FILE] (LedDevice.cpp:371) Power Off
2022-03-26T14:40:32.982Z [LEDDEVICE_FILE] (LedDevice.cpp:293) Set LED strip to black/power off
2022-03-26T14:40:32.982Z [LEDDEVICE_FILE] (LedDeviceFile.cpp:83) File: NULL
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
So I have HyperHDR up and working great. I just have one problem. The lights don't turn off without manual intervention on the web page.
I have an always-on Roku Ultra as the source. It goes through an HDMI switch, to an HDMI splitter and on to the capture board.
I tried automatic calibration but that did not work, so I tried manual calibration. I set the Roku to go to an all-black screensaver after 5 minutes. Turned off the TV and waited. Backlight stayed on. Still on 30 minutes later. So I go into the HyperHDR web page to check the Live feed on the LED Visualization page. Lights go out instantly. It's as if opening the page reminded the system to check if the signal had been lost.
So I looked at the logs and no, the instant the source goes black the system detects it and switched to source "priority channel 254". I had thought a loss of signal would force it to idle state and thus the background effect (mine is set to black (0,0,0) of Priority channel 255, but no.
Any suggestions? I have reproduced this several times. Not sure if I have something misconfigured or what.
Beta Was this translation helpful? Give feedback.
All reactions