hyperion.ng
hyperion.ng copied to clipboard
hyperion-project
Capture source is not updating display dropdown according to PC's current configuration
- [x] I confirm that this is an issue rather than a question.
Bug report
Connecting second screen/monitor does not automatically show and update recording select menu for displays. Hyperion needs to be restarted.
Steps to reproduce
Have 1 monitor connected Run Hyperion. Choose recording as source (no display drop menu). Connect second monitor. Refresh web page.
What is expected?
To refresh pc display configuration and show display select menu under recording source.
What is actually happening?
Display dropdown is not present.
System
Alpha 10, windows 10, normal monitor and tv
Hyperion Server:
- Build: (HEAD detached at b1a4e95c) (Paulchen-Panther-975f969a/b1a4e95c-1626550299)
- Build time: Jul 17 2021 20:53:38
- Git Remote: https://github.com/hyperion-project/hyperion.ng
- Version: 2.0.0-alpha.10
- UI Lang: en (BrowserLang: en-US)
- UI Access: default
- Avail Capt: v4l2,qt,dx
- Database: read/write
Hyperion Server OS:
- Distribution: Windows 10 Version 2009
- Architecture: x86_64
- Kernel: winnt (10.0.19042 (WS: 64))
- Qt Version: 5.15.0
- Python Version: 3.9.6
- Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Hello @FluffyDiscord
We make use of an ISSUE TEMPLATE to capture relevant information to support you best. Unfortunately, you ignored or deleted the given sections. Please take care that all information requested is provided.
This issue will be automatically closed by our bot, please do not take it personally. We would like asking you to open a new issue following the ISSUE TEMPLATE.
Thanks for your continuous support!
Best regards, Hyperion-Project
![hyperion-project[bot] avatar](https://avatars.githubusercontent.com/in/56847?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hi @FluffyDiscord can you confirm that this is applicable only for the Qt-Grabber? At my end the DX-Grabber considers updating the number of monitors (adding or removing one).
In addition, the Qt-Grabber seems not to react correctly on resolution updates... Seems we need to check on the used Qt framework itself.
Can confirm that DX does indeed update the monitor dropdown (shows and works fine), but the QT does not. I would love to use DX as a daily driver, but even when I set Capture frequency to 60, it still has some weird delay and lags from time to time. If the DX would be fixed, the QT would not need to be even there.
DX as a daily driver, but even when I set Capture frequency to 60, it still has some weird delay and lags from time to time.
If there are lags, normally there is too much workload. Increasing the frequency does not help, as it creates even more load. To reduce the processing workload, there is the size decimation parameter.
What SizeDecimation you are running with? Have you tried to increase the number? Did that help?
DX as a daily driver, but even when I set Capture frequency to 60, it still has some weird delay and lags from time to time.
If there are lags, normally there is too much workload. Increasing the frequency does not help, as it creates even more load. To reduce the processing workload, there is the size decimation parameter.
What SizeDecimation you are running with? Have you tried to increase the number? Did that help?
The default value of 8 didn't do well. Lights didn't correspond to the image on screen. I have it on 2, maybe I can put it down by one to 3. We are talking about 1080p screen, with decimation of 2 is 540p. Why would my 12 thread cpu or my trusty old rx 470 struggle?
Why would my 12 thread cpu or my trusty old rx 470 struggle?
...because the current DX and Qt grabbers only running as single thread. The USB Capture grabbers were migrated to multi-threadding, but the screen grabbers not (yet).
Edit: How many LEDs do you have per cm that you require that much granularity for color mapping (size decimation=2). Seeing a "perfect" image in the preview is different what resolution you need for LED mappings.
Why would my 12 thread cpu or my trusty old rx 470 struggle?
...because the current DX and Qt grabbers only running as single thread. The USB Capture grabbers were migrated to multi-threadding, but the screen grabbers not (yet).
Edit: How many LEDs do you have per cm that you require that much granularity for color mapping (size decimation=2). Seeing a "perfect" image in the preview is different what resolution you need for LED mappings.
Ah, then it makes sense that it would struggle. 60/m. I understand that the resolution after decimation should roughly match number of leds in the longest side, but as I said. For some reason colors of the LEDs were off, because the decimation averages(?) the block's color.
For some reason colors of the LEDs were off
Were you able to verify in the Preview that the LEDs were mapped to Black areas? Maybe you need to updated some configuration thresholds that treat areas as black.
For some reason colors of the LEDs were off
Were you able to verify in the Preview that the LEDs were mapped to Black areas? Maybe you need to updated some configuration thresholds that treat areas as black.
Sorry, I am not sure that I follow.
@FluffyDiscord Sorry that I did not expressed myself clearly. I only wanted to check, if in the Video Preview, you see the LEDs as black too. And how much size decimation might make a difference.
Just for testing, I did a 30x20 LED layout. If I run the grabber with SizeDecimation=1, 10 or 20 the LED color seems very much the same... But I just did an "artificial" test to check with you where the break might be.... Edit: I tested with Smoothing off and I think I use default color adjustments (in case this might be relevant)
1:
10:
20:
