After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 598173 - totem doesn't uninhibit the session
totem doesn't uninhibit the session
Status: RESOLVED FIXED
Product: totem
Classification: Core
Component: general
2.28.x
Other Linux
: High normal
: ---
Assigned To: GNOME Power Manager Maintainer(s)
General Totem maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2009-10-12 17:13 UTC by Jean-François Fortin Tam
Modified: 2009-11-06 01:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jean-François Fortin Tam 2009-10-12 17:13:45 UTC
Initially filed as https://bugs.launchpad.net/ubuntu/+source/totem/+bug/448438

What I'm experiencing:
- totem does seem to inhibit the screensaver (contrary to what other bug reports say), however:
- it sometimes "forgets" to release the inhibition. If you run it with --debug, you can see errors such as this one:

jeff@kusanagi:~$ totem --debug Vidéos/8-bit\ trip.mp4

(totem:4604): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Method "AllowActivation" with signature "" on interface "org.gnome.ScreenSaver" doesn't exist

** (totem:4604): WARNING **: Problem inhibiting the screensaver: Method "UnInhibit" with signature "u" on interface "org.gnome.ScreenSaver" doesn't exist

Now, I'm not sure exactly why, the inhibition sometimes seems to work, sometimes not. When it doesn't work,
- the screen will not blank anymore, the session will not go idle (and will not lock)
- if you attempt to log out of gnome, you will get a warning about totem (sometimes, multiple instances of totem!) being busy and inhibiting (while totem has only a single instance, and it is long gone).
Comment 1 Bastien Nocera 2009-10-12 17:40:25 UTC
That strikes me as a bug in gnome-screensaver not doing its job anymore, though I'd be happy looking at backtraces for the warnings you see.
Comment 2 Luis Medinas 2009-10-12 21:45:34 UTC
Bastien i can reproduce this bug i'll try to get a backtrace asap. I must say this is a upstream bug since i could reproduce it on ubuntu 9.10 and opensuse 11.2.

Steps to reproduce: - Play a movie in fullscreen, after the movie finishes, GPM makes display in sleep mode and it makes totem unusable (it doesn't crash but i have to switch to another workspace to kill totem)
Comment 3 Bastien Nocera 2009-10-12 22:02:39 UTC
I'm pretty certain this isn't a Totem bug, but I'll fix the warning. The rest is up to the gnome-screensaver, gnome-power-manager and gnome-session people to stop churning API changes every release...
Comment 4 Luis Medinas 2009-10-13 00:48:14 UTC
It doesn't look a gnome-screensaver bug, it didn't took significant changes during the 2.27.x cycle to do this bug. Assigning to g-p-m maintainer.
Comment 5 Bastien Nocera 2009-10-16 15:40:08 UTC
Warning is fixed in gnome 2.28. The error itself is a different problem.

File a separate bug if you're still seeing warnings.
Comment 6 Jean-François Fortin Tam 2009-10-16 18:18:56 UTC
Ok, but do I take that it should work/behave as expected now? (ie: not block session logout and/or inhibit the screensaver/suspend when totem isn't running anymore)
Comment 7 Bastien Nocera 2009-10-16 18:54:53 UTC
I couldn't reproduce the problem, but I can see how the original warning might happen.

Most likely, gnome-screensaver crashed, or was killed, and the gnome-session inhibition didn't notice. gnome-screensaver is supposed to proxy to gnome-session, and it should be transparent to users.

File a bug against gnome-screensaver if you still see the problem.
Comment 8 Chris Coulson 2009-11-06 01:58:08 UTC
Bastien - I've been experiencing a similar issue, and I actually tracked it down to an issue in hamster-applet. hamster-applet is currently listening to all the methods on org.gnome.ScreenSaver, but doesn't handle them in any way. This makes dbus return an error even though gnome-screensaver registers the inhibitor. The inhibitor cannot be removed again, because no cookie is ever returned.

See https://bugzilla.gnome.org/show_bug.cgi?id=600909