[mythtv-users] momentary audio drop when screensaver deactivated

[Mark Perkins]

> On 27/10/16 14:05, Michael T. Dean wrote:
>> 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.
>>>
.......
>>> 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?
....
>> 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 ...).

Just a quick follow up on this one. I tested with the xscreensaver-command
script higher up in the PATH with a generic 'exit 0' but saw no change in
behaviour. I eventually added a little bit of logging to the script to
really verify that my script was getting called and it was, it just didn't
appreciably change anything.

So I then amended the script to exit non zero (I think I chose 'exit 5' for
want of a better number). And this does appear to have completely solved the
problem (or I guess more accurately, at least masked it).

But that just left me more confused. So if an empty bash script with exit 0
still triggers the issue, but an empty bash script with exit 5 does not,
where does that mean the likely problem is likely to be?

This is top during playback which shows about 13% cpu usage (Standard defn
recording I think). I have 4Gb memory which is nearly fully used but swap
memory is 240 bytes so that doesn't seem likely to be the problem?

top - 19:40:53 up 2 days,  1:54,  3 users,  load average: 0.59, 0.21, 0.07
Tasks: 184 total,   1 running, 183 sleeping,   0 stopped,   0 zombie
%Cpu(s): 10.5 us,  2.0 sy,  0.0 ni, 87.4 id,  0.0 wa,  0.0 hi,  0.1 si,  0.0
st
KiB Mem:   4045152 total,  3735884 used,   309268 free,   108144 buffers
KiB Swap:  4194300 total,      240 used,  4194060 free.  2588108 cached Mem

Thanks again Mike and Stuart for the assistance. If you have any more
troubleshooting pointers they would be greatly appreciated.