Review Request 112076: Fix bug where monitor won't powersave even with only audio content

[James Smith]

> On Jan. 17, 2014, 9:01 a.m., Harald Sitter wrote:
> > src/app/mainWindow.cpp, line 868
> > <https://git.reviewboard.kde.org/r/112076/diff/9/?file=234120#file234120line868>
> >
> >     While super lovely, this unfortunately suffers from the problem I outlined in a comment for review5.
> >     Essentially video availability is async and independent of state change. Namely hasVideo doesn't need to be true when entering PlayingState (in fact it mostly isn't with Phonon VLC). So doing the static hasVideo is not sufficient. Instead engineHasVideoChanged() needs to be utilized in some form or fashion (wired up to Phonon, slot is called whenever hasVideo changed).
> >     
> >     My original comment from back then was:
> >     
> >     What I just remembered though... Phonon dispatches this information as a signal (i.e. state changes to playing; 3 seconds later; signal for hasVideoChanged arrives indicating this is audio-only content), so checking hasVideo() at the time of state change can lead to wrong behavior (e.g. hasVideo=false; 3 seconds later; hasVideo=true).
> >     
> >     So yes, likely engineHasVideoChanged() is where you want to have additional logic.
> >     
> >     Perhaps something like this:
> >     new function MainWindow::inhibitSleep() [example name :S; contains sleep logic from inhibitPowersave()]
> >     new function MainWindow::releaseSleep() [contains release for sleep logic from releasePowersave()[]
> >     new function MainWindow::inhibitScreenSleep() [contains screen power management from inhibitPowersave()]
> >     new function MainWindow::releaseScreenSleep() [contains release for screen power management from releasePowersave()]
> >     remove function MainWindow::inhibitPowersave() [release can be kept around as convenience function)
> >     MainWindow::engineStateChanged(...) calls MainWindow::inhibitSleep() [assumption: we always want to prevent sleeping]
> >     MainWindow::engineHasVideoChanged(...) it calls MainWindow::inhibitScreenSleep() if hasVideo=true, or calls MainWindow::releaseScreenSleep() if hasVideo=no [overall condition: state must be playing]
> >     [on state change to !playing we continue to call releasePowersave(), which in turn calls both releseSleep() and releaseScreenSleep()]
> >     
> >     ultimate result is then that we always prevent sleeping
> 
> James Smith wrote:
>     I had a problem with having separate screen functions in engineHasVideoChanged() where Dragon was unstable and generally crashed a ton.
>     
>     Fortunately with both backends I've tested (VLC and GStreamer) in the terminal I get a nice KNotificationRestrictions debug message that appears when the video stream starts, and also reappears when the stream is paused and resumed. I think the original problem was that I was not requesting that hasVideo apply to KNotificationRestrictions.
> 
> Harald Sitter wrote:
>     It's a timing problem, whether or not it will fail entirely depends on timing.
>     
>     https://projects.kde.org/projects/kdesupport/phonon/phonon-vlc/repository/revisions/master/entry/src/mediaplayer.cpp#L262
>     
>     As you can see hasVideo changes are in no way bound to states. Yet the proposed diff will only evaluate hasVideo on state changes, as if it were tied to a state change. But regardless it is not, so the proposed diff is not correct.

I don't know if calling in engineHasVideoChanged() is the best solution either, given the crashes and general unstableness. Possibly putting a single shot timer to call the inhibitPowerSave function after a 5-second timeout, but I don't really like that solution for a problem that 1) may or may not be complained about in the future and 2) that tested probabilistically nil as a practical concern.

I can't validly confirm that a three second delay does happen to cause Dragon to 1) only some of the time (as opposed to all the time) fail triggering a screen saver suppression immediately 2) irresponsibly trigger a screen suppression immediately anyhow, despite having a delay.


- James


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/112076/#review47557
-----------------------------------------------------------


On Jan. 16, 2014, 11:26 a.m., James Smith wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/112076/
> -----------------------------------------------------------
> 
> (Updated Jan. 16, 2014, 11:26 a.m.)
> 
> 
> Review request for KDE Multimedia and Harald Sitter.
> 
> 
> Repository: dragon
> 
> 
> Description
> -------
> 
> Fixes an issue where playing audio content keeps the screen awake. Video content is supposed to, but with the new play URL button, dragon should allow the monitor to turn off.
> 
> 
> Diffs
> -----
> 
>   src/app/mainWindow.cpp f850820 
> 
> Diff: https://git.reviewboard.kde.org/r/112076/diff/
> 
> 
> Testing
> -------
> 
> Compile, run-test
> 
> 
> Thanks,
> 
> James Smith
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20140117/f4f8acd4/attachment.htm>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia