"This monitor is not controllable" randomly after hibernation

[Intenditore]

I'm freaking tired of this(

[N0nd]

also on my monitor or something!, DDC/CI enabled

[N0nd]

after the closure of the despetcher task

[Intenditore]

I have to perform the same thing, only restarting the program helps

[emoacht]

Hi,
In general, it happens immediately after the resume from suspend or hibernation because the system is not yet ready to work with monitors when this app scans them. The resume event will trigger this app to rescan the connected monitors several times in the period of around 2 minutes. During such period, the system is expected to be ready so that this app can work again.
It seems that something went wrong in this process. To figure out the issue, could you perform the probe function as explained in readme in several times after the resume?

[Intenditore]

I did it. One is when the bug appears, another after restarting app
probe_disabled.log
probe_enabled.log

[emoacht]

@Intenditore Thanks for the logs.
However, unfortunately, the log does not capture the situation when the monitor in question returns an erroneous response and leads to cause this issue. Ideally, to make sure what exactly happens, the responses during the multiple timing after the resume would be necessary. It means immediately after the resume, 5 seconds, 10 seconds, 20 seconds, 40 seconds, 80 seconds and 160 seconds after the resume.
Its not a simple bug but finding the way to handle the erroneous response from some monitors as gracefully as possible.

[emoacht]

Modified by 91d1563
It changes the condition to determine the controllable state of a monitor.

[Intenditore]

Modified by 91d1563
It changes the condition to determine the controllable state of a monitor.

Sorry, but it's not really working. I get the message (glowing red now :D) much more frequently and does not go away for a long time forcing me to restart the app. Here's the log collected when this message appears.
probe.log

[emoacht]

Thank you for the report.
I found that in some cases, a rush of messages interrupts the sequence of re-scanning monitors and it may cause an accumulation of failure counts almost instantly. To solve this issue, I reconfigured the scan timings in 4ea9edf and set interval for scan in 794549d.

[Intenditore]

Weird, I updated to 2.1.0, but the problem persists

[emoacht]

It is implemented in Ver 2.2.0. Try its pre-release.

[Intenditore]

Dear @emoacht, you will laugh (or cry), but... It happened again!
probe.log

[emoacht]

Thank you for reporting again.
For the moment, try Ver 2.3.0 and see if there would be any difference.

[emoacht]

If this issue happens again, try Ver 2.4.0 with making operation log as described in readme. The operation log would provide much better information to track what really happens.

[chivoyage]

This happens to me all the time on 2.4.0 after waking up from sleep. Only restarting helps. In the last version, even restarting didn't help but in 2.4.0, restarting helps each time. But still, seeing this bug all the time makes it annoying.

[emoacht]

I see.
Make and save operation.log as described in readme and post it with the time when the issue happened.

[chivoyage]

operation.log
Happens right after a PC resume from sleep. But it's been fixing itself if given a bit of time.

[emoacht]

@chivoyage Thanks for the log.
It tells that:
15/03/2020 10:23:51 - OS resumed.
15/03/2020 10:23:52 - The first scan after resume found that the monitor is unreachable. It means that OS did not return expected response to API calls. It is quite common immediately after resume.
15/03/2020 10:23:58 - The second scan after resume found the monitor returned to normal.
So you had only 6 seconds window. You are very good at taking the screenshot!

Well, there is nothing surprising. The monitor returned to normal state within very short period. It is completely expected behavior.

[chivoyage]

In this case, it returned quickly but sometimes, I click the tray icon like 25 times for 1-2 minutes and it's the same message. I'll post a video and log soon.

…

________________________________ From: emoacht <notifications@github.com> Sent: 16 March 2020 13:21 To: emoacht/Monitorian <Monitorian@noreply.github.com> Cc: Chi <c-dan@live.com>; Mention <mention@noreply.github.com> Subject: Re: [emoacht/Monitorian] "This monitor is not controllable" randomly after hibernation (#50) @chivoyage<https://github.com/chivoyage> Thanks for the log. It tells that: 15/03/2020 10:23:51 - OS resumed. 15/03/2020 10:23:52 - The first scan after resume found that the monitor is unreachable. It means that OS did not return expected response to API calls. It is quite common immediately after resume. 15/03/2020 10:23:58 - The second scan after resume found the monitor returned to normal. So you had only 6 seconds window. You are very good at taking the screenshot! Well, there is nothing surprising. The monitor returned to normal state within very short period. It is completely expected behavior. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#50 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHIB6RTHUV4D42EOGCYFZJ3RHYKUDANCNFSM4IQCAQ5Q>.

[chivoyage]

Here's a video - https://youtu.be/cwGmIeVX2ec (4k)
This log is the one I produced at the end in the video.
operation.log

Thanks,
Chi

[chivoyage]

Had a few more instances where even restarting the app multiple times didn't help but then I realised that restarting the graphics drivers helps. (ctrl+shift+win+b) I'm using Nvidia.

[emoacht]

I close this issue because it seems to related to #75