Red Hat Bugzilla – Bug 432800
gxine not inhibiting screensaver
Last modified: 2009-07-14 14:11:12 EDT
Description of problem:
gxine does not inhibit screensaver activation on Rawhide, both in windowed mode
(with the appropriate switch toggled), and in fullscreen mode.
Totem still does, on the same system, and both programs' inhibition code look
virtually identical (since gxine's code is basically Totem's). Bizarre!
(gxine is also prone to lock-up when using Metacity's new compositor, but I've
not reliably reproduced that -- apart from it involving using the mouse in the
first few seconds, triggering a Metacity screen repaint, so that can wait)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Set gxine's "Prevent blanking in windowed mode" switch
2. Play a video file (or some music files)
3. Sit and wait (for faster effect, set your screensaver to toggle really early)
Screensaver is triggered
Would be nice if gnome-screensaver can report if it's being inhibited or not.
Filing a bug there
Could you try latest hg snapshot if it behaves better (hg clone
http://hg.debian.org/hg/xine-lib/gxine)? I don't have a rawhide machine around
to test it right now... I have been considering update in rawhide to hg snapshot
for a while now, since there seems to be quite nice new features and I didn't
noticed any regressions so far. If it fixes the screensaver issue, it would be
another reason to update...
Unfortunately I just downgraded back to F8 (to try VMware -- I've since switched to KVM -- and so I have
access to a GCC that's older than 4.3). I'll try and reproduce the bug with Rawhide-as-a-guest-OS, and if
that works, try the snapshot. Debian's hosting it now??
Back on Rawhide. gxine trunk appears to be in a rather unstable state right now
-- the Makefile target that generates the desktop file with proper MIME type is
buggy (missing semicolon between video/x-quicktime and video/quicktime); also,
the program create its video frame outside the main window (and does not respond
The code to handle screensaver is unchanged in Hg, and also appears to be
unchanged in Rawhide's Totem. Out of curiosity, I added printf statements in
gtv_screensaver_inhibit_dbus -- and found that they were never called!
While we're at this, any idea how to fix this?
warning: configuration item media.audio_cd.cddb_cachedir points to a
non-existent location /local/home/michel/.xine/cddbcache
warning: configuration item media.capture.save_dir points to a non-existent
warning: configuration item media.video4linux.radio_device points to a
non-existent location /dev/radio0
This causes the every attempt to access the Configure->Preferences menu to be
very slow (tens of seconds of delay). Is there a way to disable the radio device
(In reply to comment #3)
> Back on Rawhide. gxine trunk appears to be in a rather unstable state right now
> -- the Makefile target that generates the desktop file with proper MIME type is
> buggy (missing semicolon between video/x-quicktime and video/quicktime); also,
This one I am aware of and is easy to fix when needed for rpm packaging
> the program create its video frame outside the main window (and does not respond
> to input).
Hm... another GCC4.3 thing? This does not happen on F8 :/
> The code to handle screensaver is unchanged in Hg, and also appears to be
> unchanged in Rawhide's Totem. Out of curiosity, I added printf statements in
> gtv_screensaver_inhibit_dbus -- and found that they were never called!
That sounds rather strange. Something must be broken, but what? Would you mind
submitting this bug upstream? It could have higher changes of getting fixed.
> While we're at this, any idea how to fix this?
> warning: configuration item media.audio_cd.cddb_cachedir points to a
> non-existent location /local/home/michel/.xine/cddbcache
> warning: configuration item media.capture.save_dir points to a non-existent
> warning: configuration item media.video4linux.radio_device points to a
> non-existent location /dev/radio0
> This causes the every attempt to access the Configure->Preferences menu to be
> very slow (tens of seconds of delay). Is there a way to disable the radio device
> by default?
I noticed some similar bahaviour when adding files to playlist with my dvd drive
closed... It sure is annoying. I would also suggest to move this upstream, I
don't have an idea how to fix this.
btw. upstream's new bugzilla is at http://bugs.xine-project.org/
(In reply to comment #4)
> > the program create its video frame outside the main window (and does not respond
> > to input).
> Hm... another GCC4.3 thing? This does not happen on F8 :/
Hm... I just realized it, but it might be the separate toolbar mode. Go to
Configure->Preferences; Gui->windowed_mode and uncheck *separate_toolbar* it
should do the trick. But still even in the separate toolbar mode it seems
responsive for me on F8, so there still might be a bug lurking there...
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Could you try current rawhide version (0.5.903-2)?
The playback window problem is gone, but the original non-inhibiting problem is still there. Tried it in both fullscreen and windowed mode -- no go.
By the way, could the MIME information for gxine be updated to match Totem's? It's missing things like video/x-avi
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.