[mythtv-users] momentary audio drop when screensaver deactivated

[Michael T. Dean]

On 10/27/2016 08:23 AM, Mark Perkins wrote:
> Mythbuntu: MythTV Version : v0.27.6-27-g3783dc8
>
> For quite a while I have been getting an intermittent momentary loss of
> audio of approximately 1sec during recording playback and livetv. It is not
> in the recording as rewinding and playing the scene again does not reproduce
> the audio drop in the same place. I have just realised that these audio
> drops very consistently align with this info message in the frontend (-v
> playback) logs:
>
> ScreenSaverX11Private: Calling xscreensaver-command -deactivate
>
> The odd thing is that I don't get an audio drop every time that message
> occurs (the message seems to occur quite regularly every 50seconds with -v
> playback). However having just watched a tail of the log with a show playing
> - everytime I get an audio drop I simultaneously get that message.
>
> At face value it appears that the screensaver is getting deactivated every
> 50sec, should that be happening?

Yes.

>   Or should it only happen once each session?

No, because "deactivate" means "wake up", not "turn off the screensaver 
and any protection the workstation has against a user walking away and a 
miscreant walking up and messing with it."  In other words, by design 
xscreensaver does not turn off unless the user running xscreensaver 
turns it off with "xscreensaver-command --exit" (providing safety 
against crashed processes, etc.).  This is why other newer and "better" 
approaches are bad.

> Any theories as to why this would be causing a momentary audio drop?

Likely it's a resource constraint issue--just too taxing for your system 
to do that while also playing back the audio and video with the playback 
profile options you've selected.  What specific part of "that" would 
require much more trial and error testing to determine--whether it's 
disk I/O limited and sometimes has to re-read the xscreensaver-command 
binary from HDD because it's been swapped out of memory, or CPU limited, 
or memory limited, or ...

> Any suggestions on what to do to fix or what further information might be
> required to diagnose properly?
> Can I permanently disable the screensaver so mythfrontend doesn't need to
> worry about it?

Yes.  If you turn off xscreensaver (and it must be really turned 
off--such that "xscreensaver-command --version" returns a non-zero exit 
code) when mythfrontend is started, mythfrontend won't send the 
--deactivate messages.

Note, though, that if something else turns it back on (i.e. your Display 
Manager or something), your system will sleep when "idle" for long 
periods (where idle means no keyboard/mouse input)--like during playback 
or when sitting at the menu.  And, generally, remote input won't count 
as non-idleness.  So, the hardest part of doing what you want is making 
sure that your screensaver program (all of them--including xscreensaver 
or some built-in-to-the-DM screensaver program, and the X built-in 
screen saver (controllable with xset -s) and the X built-in DPMS 
(controllable through xorg.conf)) is actually off and stays off.

Note, too, that for testing, you can make a script called 
xscreensaver-command and put it in the PATH of the user/environment 
running mythfrontend such that it's before the PATH element that 
contains the "real" xscreensaver-command program (i.e. if 
PATH=/home/mythtv/bin:/usr/local/bin:/usr/bin:/bin , then put a 
mythscreensaver-command script in /home/mythtv/bin ) that simply exits 
with 0 status:
-----
#!/bin/sh

exit 0
-----

That will be a very low-resource program to execute and can help you 
determine if it's something "higher up" than mythfrontend's spawning a 
new process (i.e. due to the size/memory requirements of 
xscreensaver-command, or the CPU requirements of xscreensaver-command, 
or the RPC done by xscreensaver-command, or ...).

Mike