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

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.


- 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/2b3ab096/attachment.htm>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia