First goto settings / interface / screensaver / set screensaver mode dim, wait time 1 minute.
Next go to settings / system / power saving / set put display to sleep when idle, set to 5 minutes.
The screensaver should dim at 1minute, then at 5 minutes the display should go into "no signal mode" allowing the tv to power off according to your tv "no signal" settings (mine is set to turn off after 15 minutes of no signal.)
The screen does not go into "no signal mode" at the 5 minute mark, instead it goes blank for a second, like it tried, but then goes back to the dim screensaver, and stays on indefinitely.
Currently if you set Screensaver to "none" instead of dim, the power saving feature will work. So I believe the Screensaver may be the culprit. Furthermore this worked properly under Kodi 17.
Used Operating system:
Why did you remove the debug log part from the issue template? Please attach.
It was easily reproduce-able so I did not think it was necessary. I am unable to test it at the moment, but will get the debug log added first thing tomorrow.
To explain: That it is easily reproducible on your system does not mean that this is the case everywhere - for example it might be DE-dependent. Anyway, looking at a debug log to get a better idea of your environment is usually one of the first things we do when analyzing a bug. I'm not sure what part of "A debuglog is always mandatory when creating an issue" (stated in the template) is unclear.
Done rambling now ;-)
AH, I missed that comment about the debug being mandator, but I probably knew better, it was just very late where I am when I submitted the bug report. Thank you for taking a look, I appreciate it.
I attached the debug log to the opening report.
Also my other system in another location has the same bug, that system was freshly installed OS and all less than a month ago, whereas this one was upgraded in place from Ubuntu 16 to 18 so it might have more cobwebs. Will get you the other debug log as well soon as I can, incase it helps.
Looking at the log, looks like line 635:
12:21:18.131 T:140058683581376 INFO: DPMS: enabled power-saving mode SUSPEND
12:21:18.131 T:140058179098368 DEBUG: CAnnouncementManager - Announcement: OnDPMSActivated from xbmc
12:21:18.131 T:140058179098368 DEBUG: GOT ANNOUNCEMENT, type: 4, from xbmc, message OnDPMSActivated
13:15:20.230 T:140058170705664 DEBUG: LIRC: - NEW 000000008001006c 00 KEY_DOWN devinput-32 (KEY_DOWN)
However I assure you, the screen never turned off, it blanked for a couple settings then went back to showing the dim screensaver and remained there for an hour.
You can see that I woke it up (from the screensaver) at 13:15 about an hour after launching kodi, I used my Ir remote KEY_DOWN
If there is a way to add any further debug info that you need, just let me know what to do and I will provide it.
I'm seeing the same behavior:
I have debugging logging enabled and this what is logged when that blink happens when the screen should be turning off:
17:01:10.645 T:139968889702976 INFO: DPMS: enabled power-saving mode SUSPEND
17:01:10.645 T:139968889689856 DEBUG: CAnnouncementManager - Announcement: OnDPMSActivated from xbmc
17:01:10.646 T:139968889689856 DEBUG: GOT ANNOUNCEMENT, type: 4, from xbmc, message OnDPMSActivated
17:01:10.646 T:139968889702976 DEBUG: started alarm with name: sssssscreensaver
17:01:10.647 T:139968743827200 DEBUG: Thread AlarmClock start, auto delete: false
17:01:10.743 T:139965916808960 NOTICE: [plugin.video.elementum] DEBU main â–¶ Notification Got notification from xbmc/GUI.OnDPMSActivated: null
There aren't any messages for a minute before or a minute after.
I'm using current master a948f998d91724407ab90a89ddc0ae2745021aa0
Can reproduce, DPMS also broken for me.
@FernetMenta something come to mind or should I bisect?
Note: also happens with screensaver disabled
For me if I set the screensaver to None then my TV shuts off like it should.... let me know if there is anything else you need from me.
@pkerling doesn't ring a bell
For me if I set the screensaver to None then my TV shuts off like it should
I sincerely hope those aren't different bugs :-(
I sincerely hope those aren't different bugs :-(
They are.
Anyway, please test #14845.
Most helpful comment
To explain: That it is easily reproducible on your system does not mean that this is the case everywhere - for example it might be DE-dependent. Anyway, looking at a debug log to get a better idea of your environment is usually one of the first things we do when analyzing a bug. I'm not sure what part of "A debuglog is always mandatory when creating an issue" (stated in the template) is unclear.
Done rambling now ;-)