If DragonPlayer is left to play past the suspend clock according to Dragon's time remaining readout, upcoming suspend fails if the machine is left unattended for the full suspend countdown t- the end of movie (and lifting of inhibition event) according to DragonPlayer. If DragonPlayer is also closed after an extended inhibit event, suspend behaviour returns to normal. Reproducible: Always Steps to Reproduce: 1. Set suspend countdown to 20 mins. 2. play a 23+ minute movie in DragonPlayer 3. Wait on the computer to not sleep using, for example, an wall clock, which will succeed. Actual Results: Kde doesn't actually fall asleep without (obviously) closing DragonPlayer instead of leaving computer unattended to complete a sleepcycle according to preset hibernate-suspend timeout. Expected Results: DragonPlayer shouldn't have blocked the suspend event even while remaining open, irregardless of the movie / video / playlist length. Solid should have reset the countdown when the suspend was lifted (perhaps only when the time between inhibit and uninhibit events exceeds the suspend timer) in order to allow Dragon and other programs to allow a proper suspend after finishing a long and distinguished and productive time of execution. The same behaviour has been seen using software that also uses PowerDevil to inhibit suspend and resume, and also reenable suspend ( with identical behaviour with and without overrunning the timeout).
Reproduced here.
Another way to reproduce this/related bug: 1. run Amarok git that does suspend inhibition 2. configure Solid to suspend on lid close 3. add one song to Amarok playlist, play it 4. Close lid, Amarok playback inhibits suspend 5. The playback ends, Amarok stops inhibiting 6. Nothing happens, while the system should've suspended as the lid is closed and no reason to inhibit suspend exists
Still valid in 5.x, re-assigning there, also it qualifies as a bug imho.
Git commit bf9bf79c92a3d77df863d15c543f7f5329a564dc by Kai Uwe Broulik. Committed on 06/06/2015 at 20:25. Pushed by broulik into branch 'master'. Simulate user activity when inhibitions change This way when an inhibition outlasts an idle action (eg. 10 minute timeout for auto-suspend but download takes 11 minutes) we make sure that 10 minutes after the download has finished, the system suspends, as well as vice-versa when a video stops after 9 minutes the system waits another 10 to suspend rather than suspending within the next minute. Since this patch has the potential for unwanted side-effects (screen waking up when download finishes, I could imagine) I'll leave this as 5.4 material and not part of the 5.3.x patch releases to give it more thorough testing. FIXED-IN: 5.4.0 M +6 -0 daemon/powerdevilcore.cpp http://commits.kde.org/powerdevil/bf9bf79c92a3d77df863d15c543f7f5329a564dc