With upcoming changes to data protection and privacy laws in Europe coming into effect soon, we thought this would be a good time to remind everyone that we do have a privacy policy.
This applies to all users and visitors world-wide.

We have made a few changes to the language to make it clearer in relation to this new regulation but fundamentally, the terms and your rights are unchanged.

If you have any questions about this, please feel free to ask in the General Forum

Handbrake somehow inhibiting display standby?

Support for HandBrake on Linux, Solaris, and other Unix-like platforms
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
Post Reply
mod16
Posts: 78
Joined: Sun Jan 12, 2014 11:10 am

Handbrake somehow inhibiting display standby?

Post by mod16 » Fri Aug 11, 2017 6:19 pm

I know this is a weird question, but it's also a strange issue. It may also not be related to Handbrake at all.

I'm using KDE on Manjaro Linux. I'm building Handbrake from source.

In KDE, I've set the display/monitor standby to 20 minutes - and I'm having the issue, that sometimes the display just doesn't turn off as it should be. After a while I realized, that this issue occurs only when the Handbrake GUI is open and encoding. The display does turn off (after the idle time) if the GUI is only open but no job is running. So far Handbrake seems to be the only application having this influence on the standby mode.

Now if I run "xset -q" while Handbrake GUI is open but idle, I get:

Code: Select all

$ xset -q
[...]
DPMS (Energy Star):
  Standby: 1200    Suspend: 1800    Off: 2400
  DPMS is Enabled
  Monitor is On
But as soon as a job is running, it get:

Code: Select all

$ xset -q
[...]
DPMS (Energy Star):
  Standby: 0    Suspend: 0    Off: 0
  DPMS is Disabled
If I stop encoding or the queue finishes, I get the output above again (DPMS enabled).

So I'm not sure where to look next!? Why is it doing this? Any ideas?

The only idea I have for now is to test other CPU intensive programs, if they produce the same result. But still I would have no idea why? I really can't imagine an OS or DE "feature" that disables display standby if there is a high CPU load. :wink: :D

Just wanted to ask here if anyone maybe had the same issue?

User avatar
JohnAStebbins
HandBrake Team
Posts: 5117
Joined: Sat Feb 09, 2008 7:21 pm

Re: Handbrake somehow inhibiting display standby?

Post by JohnAStebbins » Mon Aug 14, 2017 5:08 pm

The HandBrake GUI tries 2 dbus interfaces to request that power management be suspended during encoding. First it tries org.gnome.SessionManager, then it tries org.freedesktop.PowerManagement. Neither of these interfaces are very well documented which is frustrating (I guess you get what you pay for :mrgreen:). This should only be disabling session and computer suspend functions. As far as I understand, this shouldn't affect screen locks or display power settings. But the documentation on these interfaces is not terribly clear (in fact it's pretty much non-existent).

I haven't received any other reports of the screen power settings being modified, but I'll do a little digging to see if I can find out more.

mod16
Posts: 78
Joined: Sun Jan 12, 2014 11:10 am

Re: Handbrake somehow inhibiting display standby?

Post by mod16 » Thu Aug 17, 2017 9:36 am

Thank you for your reply and additional information! At least the behavior makes some sense now. :)

If you need more information on used Kernel, libs etc. I'm happy to provide it.

If I myself find any useful "discoveries" I will also report back here.

mod16
Posts: 78
Joined: Sun Jan 12, 2014 11:10 am

Re: Handbrake somehow inhibiting display standby?

Post by mod16 » Sun Nov 19, 2017 1:39 pm

*bump*

Just wanted to bring this up again to see if maybe someone else also has this issue? Or is it really just me? :)

mod16
Posts: 78
Joined: Sun Jan 12, 2014 11:10 am

Re: Handbrake somehow inhibiting display standby?

Post by mod16 » Thu Mar 01, 2018 7:34 pm

My display goes to sleep now again if Handbrake is encoding. :D

I assume, it's related to this commit:
https://github.com/HandBrake/HandBrake/ ... 38181829ba

At least the last build from a few days ago still had the issue and now it seems to work again.

User avatar
JohnAStebbins
HandBrake Team
Posts: 5117
Joined: Sat Feb 09, 2008 7:21 pm

Re: Handbrake somehow inhibiting display standby?

Post by JohnAStebbins » Thu Mar 01, 2018 10:01 pm

Yes, that is the only change that could have had any effect on this. Hopefully it now inhibits suspend mode without affecting display sleep mode.

napulob
Posts: 3
Joined: Sun Oct 01, 2017 1:09 pm

Re: Handbrake somehow inhibiting display standby?

Post by napulob » Sun Mar 04, 2018 11:58 pm

Hey, just thought to mention, I am too using Manjaro, but I have been using the depository Handbrake version. I have set the screen power so that the screen goes to low power mode after one minute and turns off after a few minutes. When Handbrake is encoding, the screen goes to the low power mode, but doesn't power off. When Handbrake is done encoding, the screen actually brightens up again, without me touching the machine. Then it can go to low power again, and then turn off.

I havent really worried about this, as when the screen brightens up again I get notified in that way that the encoding is done, if I'm not actually using the computer but can see the screen :)

Maybe this has been a Manjaro/Arch related issue? But if it is fixed, maybe I'll try to compile Handbrake myself, as I've learned that the Arch/Manjaro packaged version is broken somehow anyways (probably unrelated to this, as compiling from source didn't solve the issue before).

Post Reply