[mythtv-users] first remote button press is ignored

Stuart Auchterlonie stuarta at squashedfrog.net
Tue Jan 30 14:34:33 UTC 2018


On 28/01/18 19:14, Joey Morris wrote:
> Roger Siddons <dizygotheca at ntlworld.com> wrote on Thu, Jan 25, 2018 at 10:06:53AM +0000:
>> On Wed, 24 Jan 2018 22:47:00 -0500
>> Joey Morris <rjmorris.list at zoho.com> wrote:
> 
> Mythfrontend's DBus/screensaver behavior appears to be the source of the issue.
> I describe a solution at the end of this message, although I wonder if there is
> a better one.
> 
> Adding some log messages to the section of code Roger is referring to (in the
> MythMainWindow::customEvent function in libs/libmythui/mythmainwindow.cpp), I
> saw that the first button press was ignored because the following condition was
> true:
> 
>     if (GetMythUI()->GetScreenIsAsleep())
>         return;
> 
> So MythTV thinks my screen is asleep when it receives the first button press.
> But why?


This is a very good question. The logical flow should be

"start playback" -> inhibit screensaver
"stop playback" -> re-renable screensaver

Now in order for your screen to be "asleep" the screensaver time out
should have expired and the screensaver kicked in.

Is this the case?

> 
> I have these messages in my log when I start mythfrontend:
> 
>     screensaver-dbus.cpp:61 (ScreenSaverDBusPrivate) - ScreenSaverDBus:
>       Created for DBus service: org.freedesktop.ScreenSaver
>     screensaver-dbus.cpp:57 (ScreenSaverDBusPrivate) - ScreenSaverDBus:
>       Could not connect to dbus: The name org.freedesktop.PowerManagement.Inhibit
>       was not provided by any .service files
>     screensaver-dbus.cpp:57 (ScreenSaverDBusPrivate) - ScreenSaverDBus:
>       Could not connect to dbus: The name org.mate.SessionManager was not
>       provided by any .service files
>     screensaver-dbus.cpp:57 (ScreenSaverDBusPrivate) - ScreenSaverDBus:
>       Could not connect to dbus: The name org.gnome.SessionManager was not
>       provided by any .service files
>     screensaver-x11.cpp:82 (ScreenSaverX11Private) - ScreenSaverX11Private:
>       DPMS is disabled.
> 
> When I begin playback, I have this message:
> 
>     screensaver-dbus.cpp:82 (Inhibit) - ScreenSaverDBus:
>       Successfully inhibited screensaver via org.freedesktop.ScreenSaver.
>       cookie 63. nom nom
> 

So that's correct, when you start playback the screen saver is inhibited.

> And then immediately after the first button press (the one that is ignored), I
> have this message:
> 
>     screensaver-dbus.cpp:102 (UnInhibit) - ScreenSaverDBus:
>       Screensaver uninhibited via org.freedesktop.ScreenSaver
> 

This is re-enabling the screen saver.
So if the screensaver was inhibited, then how can the screen
possibly be asleep?


> Searching for these messages led to a few tickets and mailing list threads:
> 
>     https://code.mythtv.org/trac/ticket/12435
>     https://code.mythtv.org/trac/ticket/12438
>     https://lists.gt.net/mythtv/dev/585861
>     https://lists.gt.net/mythtv/users/593738
> 
> The mailing list threads are a little old (2015), long, and may not be entirely
> relevant to this particular case, but I'm including them for reference.
> 
> Based on a comment in https://code.mythtv.org/trac/ticket/12435, I recompiled
> with --disable-qt5dbus, and the first button press is no longer ignored! None of
> the above log messages appear anymore except this one when mythfrontend starts:
> 
>     screensaver-x11.cpp:82 (ScreenSaverX11Private) - ScreenSaverX11Private:
>       DPMS is disabled.
> 
> Just to recap my setup: I'm running mythtv 29 on Debian Buster with XFCE, no
> screensaver installed, and DPMS disabled. I don't have any particular reason to
> avoid a screensaver or DPMS; I just haven't seen a need for them on this
> machine.
> 

Does your screen ever actually go to sleep?
>From the data you have provided, we are talking over dbus and
successfully disabling the screen saver.

Looking at the code
https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythui/screensaver-dbus.cpp#L68-L90

if we get a successful reply from dbus (ie. a non error reply)
then we set m_inhibited, which ultimately designates if the screen
is asleep.

Am i right in inferring that because you don't use dpms / screensaver
etc, then the screen never actually shuts off?

However the code assumes that because it had a non error response, that
there is actually a screensaver doing something.

The only thing i can suggest it pulling apart the dbus reply and
seeing if it is replying with a non error response, which indicates
no screen saving has actually been done / or is possible.

> So compiling with --disable-qt5dbus is a solution, but is it the right solution?
> Does other mythfrontend functionality rely on dbus that will be affected by this
> change? Should I just install a screensaver?
> 

I don't think disabling dbus is the right solution, but others
think it is.

I would be keen to better understand why we get a non error response.

It would also be interesting to see if the actual current state of
the sleeping of the screen could be queried via dbus. That would be
more correct..


Regards
Stuart



More information about the mythtv-users mailing list