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 133011 - GConf server doesn't return a default value, but --direct does
GConf server doesn't return a default value, but --direct does
Status: RESOLVED DUPLICATE of bug 152175
Product: GConf
Classification: Deprecated
Component: gconf
2.8.x
Other Linux
: High major
: ---
Assigned To: GConf Maintainers
GConf Maintainers
: 133727 134623 136149 140453 144179 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-01-30 22:05 UTC by Sanjay Kumar J
Modified: 2005-01-21 12:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
work-around for xine-lib (2.03 KB, patch)
2004-03-16 19:25 UTC, Bastien Nocera
none Details | Review
gconf-test.c (941 bytes, text/plain)
2005-01-21 11:04 UTC, Bastien Nocera
  Details

Description Sanjay Kumar J 2004-01-30 22:05:33 UTC
the changes made to the preference->display->color balance in totem is
reflecting on other media players like mplayer. The changes are made
permenaent for other players.
Comment 1 Bastien Nocera 2004-02-18 12:17:25 UTC
*** Bug 133727 has been marked as a duplicate of this bug. ***
Comment 2 Bastien Nocera 2004-02-18 12:17:34 UTC
*** Bug 131337 has been marked as a duplicate of this bug. ***
Comment 3 Bastien Nocera 2004-02-18 12:17:47 UTC
*** Bug 134623 has been marked as a duplicate of this bug. ***
Comment 4 Bastien Nocera 2004-02-19 10:47:48 UTC
It looks like the GConf schemas weren't installed properly.
Comment 5 Sebastien Bacher 2004-02-23 20:16:46 UTC
Ok, problem still here, doesn't seems to be a schema problem (if you
think so could you point the keys to check ?). Several users have the
problem (debian and mandrake), reverting to 0.99.8 fix the issue.

User 1: debian unstable
$ gconftool-2 --get /apps/totem/hue
32767

xfree 4.3.0 debian
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4
MX 440] (rev a3)
driver "nv"

User2: mandrake cooker
same problem with "nv" and "nvidia" drivers

User3: debian unstable
geforce 2 gts
drivers nvidia


Ok, seems to be a problem with nvidia cards (xfree or nvidia drivers) ....
Comment 6 Frederic Crozat 2004-02-25 17:00:10 UTC
also seen on mdk cooker : http://qa.mandrakesoft.com/show_bug.cgi?id=7917
Comment 7 Bastien Nocera 2004-02-25 17:23:28 UTC
This is a bug only happening with NVidia cards, and I suppose this
could be worked around in the X driver.

I'm waiting for Sebastien to open a bug for XFree86 before closing
this bug.
Comment 8 Bastien Nocera 2004-03-05 09:30:35 UTC
*** Bug 136149 has been marked as a duplicate of this bug. ***
Comment 9 Bastien Nocera 2004-03-13 14:35:28 UTC
Please test.

2004-03-13  Bastien Nocera  <hadess@hadess.net>
                                                                     
          
        * NEWS: updated
        * src/bacon-video-widget-xine.c:
        (bacon_video_widget_instance_init), (setup_config_stream),
        (xine_event): don't set the image settings if they already are set
        (possibly Close: #133011)
        remove the white artifacts work-around, doesn't work properly
Comment 10 Frederic Crozat 2004-03-15 15:37:04 UTC
Patch is not working correctly : 
 
XV HUE is working strangely with NVidia driver : 
 
output of xvattr : 
Found Xv 2.2 
Adaptor: 0 
Name: NV17 Video Overlay 
 Port: 111 
 Name: XV_HUE 
   Flags: XvGettable XvSettable 
   Min value: 0 
   Max value: 360 
   Current value: 0 
 
by default, it starts with value = 0 
 
<fcrozat> xvattr -a XV_HUE -v 0 -p 111 => colors are fine 
<fcrozat> xvattr -a XV_HUE -v 359 -p 111 => colors are fine 
<fcrozat> xvattr -a XV_HUE -v 180 -p 111 => colors are ugly 
Colors are correct with value = 0 or 359. Colors are completely 
screwed when value = 180. 
 
Other adaptator broken : 
  Adaptor #0: "NV Video Overlay" 
 
I think we need to discard HUE setting when Adaptor is "NV* Video 
Overlay" (I can't test the TV output one). 
 
Just tested on ATI card with proprietary driver : 
hue min = -1000 
hue max = 1000 
colors are correct when hue = 0 
 
it seems the NV driver have the inverse behaviour than the ATI one :
(( 
 
 
Comment 11 Bastien Nocera 2004-03-16 19:24:30 UTC
A work-around has been committed to xine-lib:
  * ignore the hue setting on NVidia cards using the Xv video output
    as both the XFree86 and the proprietary driver are broken

Bug your hardware vendor about getting it properly fixed :)
Comment 12 Bastien Nocera 2004-03-16 19:25:27 UTC
Created attachment 25698 [details] [review]
work-around for xine-lib
Comment 13 Bastien Nocera 2004-04-19 09:26:20 UTC
*** Bug 140453 has been marked as a duplicate of this bug. ***
Comment 14 Bastien Nocera 2004-06-11 18:02:16 UTC
*** Bug 144179 has been marked as a duplicate of this bug. ***
Comment 15 Matthew Gatto 2004-10-29 06:01:10 UTC
What version is this supposed to be fixed in? I'm still seeing this (I think
this bug..) with totem-0.99.15.1 (totem-0.99.15.1-0.lvn.2.2 from the livna
repository) for Fedora-2 and a Radeon 9200. I do

$ rm -rf ~/.gnome2/totem* ~/.xine*
$ gconftool-2 --recursive-unset /apps/totem

open a movie with totem, and the audio works but I get a black screen that makes
me think at first that it's a driver problem. But after poking in the
Preferences I found out that it's because all of the 'Color balances' sliders
are at the far left, and clicking the 'Reset defaults' button makes the video
appear.
Comment 16 Matthew Gatto 2004-10-29 06:02:30 UTC
Oh, and my xine-lib is version: xine-lib-1.0.0-0.lvn.0.31.rc6a.2
Comment 17 Matthew Gatto 2004-10-29 06:08:07 UTC
Reopening since it's still broken for me.
Comment 18 Bastien Nocera 2004-11-19 23:41:39 UTC
Matthew, you're unlucky, I only get 2 out of the four properties breaking:

$ gconftool-2 --recursive-unset /apps/totem
$ gconftool-2 --get /apps/totem/saturation
No value set for `/apps/totem/saturation'

Whereas:
$ gconftool-2 --recursive-unset /apps/totem
$ gconftool-2 --get /apps/totem/contrast
32767

There's something fishy going on here.
$ gconftool-2 --shutdown
$ gconftool-2 --direct --config-source xml::/etc/gconf/gconf.xml.defaults --get
/apps/totem/hue
Resolved address "xml::/etc/gconf/gconf.xml.defaults" to a read-only
configuration source at position 0
None of the resolved addresses are writable; saving configuration settings will
not be possible
32767
$ gconftool-2  --config-source xml::/etc/gconf/gconf.xml.defaults --get
/apps/totem/hue
No value set for `/apps/totem/hue'

It looks like there's a bug in the server side of GConf, somewhere. I worked
around this problem in Totem by using gconf_client_get_without_default() instead
of gconf_client_get_int(), but the GConf side of the bug remains.

2004-11-19  Bastien Nocera  <hadess@hadess.net>

        * src/bacon-video-widget-xine.c: (setup_config_stream): work-around
        GConf not returning a default value when there is actually one,
        and making the video all black (Closes: #133011)
Comment 19 Bastien Nocera 2005-01-21 10:47:20 UTC
Reproduced on a RHEL4 machine.

$ gconftool-2 --get /desktop/gnome/url-handlers/http/enabled
No value set for `/desktop/gnome/url-handlers/http/enabled'
$ gconftool-2 --direct --config-source xml::/etc/gconf/gconf.xml.defaults --get
/desktop/gnome/url-handlers/http/enabled
<snip>
true
Comment 20 Bastien Nocera 2005-01-21 11:04:56 UTC
Created attachment 36327 [details]
gconf-test.c

This testcase tries to get the value of a key (and gets FALSE), then tries to
get the value again after clearing the cache, and finally the same value
without any defaults.

$ ./gconf-test
got 0
got 0

** (gconf-test:7005): WARNING **: error getting the conf value, no reason
$ gconftool-2 --direct --config-source xml::/etc/gconf/gconf.xml.defaults --get
/desktop/gnome/url-handlers/http/enabled
<snip>
true
Comment 21 Mark McLoughlin 2005-01-21 11:25:03 UTC
Don't get that here :

$ ./gconf-test
got 1
got 1

** (gconf-test:6783): WARNING **: error getting the conf value, no reason
$ gconftool-2 --direct --config-source xml::/etc/gconf/gconf.xml.defaults --get
/desktop/gnome/url-handlers/http/enabled
true

That's with GConf HEAD and GConf in FC3 after setting and unsetting the key a
few times ..
Comment 22 Bastien Nocera 2005-01-21 11:47:43 UTC
$ gconftool-2 --get /desktop/gnome/url-handlers/http/enabled
No value set for `/desktop/gnome/url-handlers/http/enabled'
$ LC_ALL=C gconftool-2 --get /desktop/gnome/url-handlers/http/enabled
true
Comment 23 Bastien Nocera 2005-01-21 12:34:27 UTC

*** This bug has been marked as a duplicate of 152175 ***