This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 432800 - gxine not inhibiting screensaver
gxine not inhibiting screensaver
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gxine (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Martin Sourada
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-14 08:48 EST by Michel Alexandre Salim
Modified: 2009-07-14 14:11 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 14:11:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michel Alexandre Salim 2008-02-14 08:48:17 EST
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):
gxine-0.5.11-17.fc9.x86_64


How reproducible:
Always

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)
  
Actual results:
Screensaver is triggered

Expected results:
Screensaver inhibited

Additional info:
Would be nice if gnome-screensaver can report if it's being inhibited or not.
Filing a bug there
Comment 1 Martin Sourada 2008-02-15 18:35:13 EST
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...
Comment 2 Michel Alexandre Salim 2008-02-18 18:04:00 EST
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??
Comment 3 Michel Alexandre Salim 2008-02-26 01:04:51 EST
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
to input).

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
location 
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?
Comment 4 Martin Sourada 2008-02-26 13:24:18 EST
(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
> location 
> 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/
Comment 5 Martin Sourada 2008-02-26 13:34:40 EST
(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...
Comment 6 Bug Zapper 2008-05-14 01:12:00 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Martin Sourada 2008-08-01 04:29:16 EDT
Could you try current rawhide version (0.5.903-2)?
Comment 8 Michel Alexandre Salim 2008-08-26 19:08:52 EDT
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
Comment 9 Bug Zapper 2009-06-09 19:33:28 EDT
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Bug Zapper 2009-07-14 14:11:12 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.