[mythtv-users] momentary audio drop when screensaver deactivated

Stuart Auchterlonie stuarta at squashedfrog.net
Thu Oct 27 13:14:36 UTC 2016


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.
>>
>> 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.
> 

If your system supports DBus based screensaver control, you will see
DBus messages about the screen saver in the frontend output, then you
can ditch xscreensaver and let mythtv tell the system not to suspend.

That has worked very well for me since I implemented it, and it was
backported to 0.27


Regards
Stuart Auchterlonie




More information about the mythtv-users mailing list