awawa-dev
The monitor from which the program takes colors changes.
Bug report, debug log and your config file (FULL LOGS ARE MANDATORY)
log: https://pastecode.io/s/n0hvpioo config: https://pastecode.io/s/m1mo0gii
Steps to reproduce
Wake Up the computer from sleep mode.
What is expected?
Working based on the primary (first) monitor at all time.
What is actually happening?
I have 2 monitors, HyperHdr should always work based on the primary screen. When I finish working with the computer, I do not close the system, but put it to sleep mode, when I come back after a while, I turn on the computer, which is ready to work. This happens several times a day, but sometimes it happens, although rarely (once a week), that when I turn on the computer, the colors displayed behind the monitor come from the second monitor, not the primary one. This is the case now, when I write this report and send the logs. Maybe we will be able to locate the problem. Maybe it is related to which monitor wakes up from sleep mode first, in my case it is usually the second monitor, but HyperHDR copes with this, although as you can see not always, maybe the logs will help diagnose the problem..
System
- Build: master (GitHub-95ae154/f78f6f5-1746315834)
- Build time: May 3 2025 23:49:50
- Git Remote: https://github.com/awawa-dev/HyperHDR
- Version: 22.0.0.0beta0
- UI Lang: pl (BrowserLang: pl-PL)
- Avail Capt: Windows (Microsoft Media Foundation)
- Database: read/write
HyperHDR Server OS:
- Distribution: Windows 11 Version 24H2
- Architecture: x86_64
- CPU Model: AMD Ryzen 7 5700G with Radeon Graphics
- Kernel: winnt (10.0.26100 (WS: 64))
- Qt Version: 6.5.3
- OpenSSL: OpenSSL 3.2.4 11 Feb 2025
- Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36
Hi I think it was resolved some time ago https://github.com/awawa-dev/HyperHDR/issues/779
I use the HypherHDR version from May and the problem still occurs, although as I wrote rarely.
If the user selected Display1 from (Display1|Dsiplay2) then HyperHDR will stick to the selection (and autoretry) if the only present at the moment is Diplay2 and it solved the old related issue. What theoretical solution can you suggest to me if there is a case where both monitors can report as Display1 (probably related to the gfx behavior) depending on the OS random acquire sequence?
I don't program for Windows, I don't know what capabilities the Windows API has, but maybe it's possible to identify monitors by name/model. Then it could solve the problem.
And I dont have two monitors to replicate this issue 😉 so it will take some time to find a workaround if any possible.
In your logs there is always single \\.\DISPLAY1|NVIDIA GeForce GTX 1650 display, no sign of secondary display direct existence.
Maybe because you dont use auto selection, nevertheless when starting it should detect both monitors if present. Anyway in logs there is always one display \\.\DISPLAY1|NVIDIA GeForce GTX 1650 and I cant see any simply option to retrieve a serial&manufatur id there (still would cause a problem if the user uses two identical monitors). Maybe it just needs an increase in wake-up sleep timeout? If you disable and enable it (priority 245 in the system grabber control) does it fix the issue then?
I have 2 different monitors, one smaller 24" and the and primary, larger, 32". The LED strip is on 32" monitor and I would like the colors on the wall to always be displayed taking into account the larger monitor. That's why I have Display 1 set, I don't know how the Auto option works in the case of your program, the colors are taken from the monitor that turns on first?
Maybe it just needs an increase in wake-up sleep timeout?
Which option is responsible for this?
If you disable and enable it (priority 245 in the system grabber control) does it fix the issue then?
I did this, but this problem occurs very rarely, so I need to test it.
The only potential consideration I see is that HyperHDR detects device1 when there is only one active monitor in the system and the other is initializing. Then, theoretically, it would be enough to give the system more time until it fixes the situation itself. That is why this test is important when a problem occurs, which will tell us whether restarting the grabber alone will be enough and device1 will return to its proper "place". If this does not help, then unfortunately I do not see a reasonable workaround.
I've been having problems with swapping monitors from which colors are being sampled periodically. Recently, I discovered that a third monitor appears in the Windows Device Manager under Monitors when I use the "Show hidden devices" option. Oddly enough, I've never had a monitor with the same name as the hidden one connected to my computer. When I removed the hidden monitor and left only the two I actually have connected to my computer, the problem has not recurred. Maybe that was the issue. I have no idea.