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 396194 - gnome-obex-send does not display devices
gnome-obex-send does not display devices
Product: libbtctl
Classification: Deprecated
Component: general
Other All
: Normal major
: ---
Assigned To: none
Depends on:
Reported: 2007-01-13 18:25 UTC by Martey Dodoo
Modified: 2007-07-10 21:25 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Martey Dodoo 2007-01-13 18:25:07 UTC
Please describe the problem:
gnome-obex-send does not display found Bluetooth devices in its GUI.

Steps to reproduce:
1. Run gnome-obex-send.
2. Click "Refresh."
3. Nothing happens.

Actual results:
While the command line displays the following output, but no devices appear in the dialog:
conn_request:   bdaddr 00:18:13:1E:5E:95
conn_complete:  status 0x00
** Message: device 00:18:13:1E:5E:95 W810i found
** Message: inquiry complete

Expected results:

Does this happen every time?

Other information:
Comment 1 zerohalo 2007-01-17 14:02:52 UTC
I confirm the exact same behavior on my machine (running Ubuntu Edgy). A number of people have reported the same problem on the Ubuntu launchpad (see above link). 

The problem is explained here:

Starting with bluez-utils-3.x we set the adapter into Inquiry with RSSI if it supports it and most Bluetooth 1.2 or later ones do. So in this mode you will see HCI_Inquiry_Result_With_RSSI and no longer HCI_Inquiry_Result events. Since the gnome-bluetooth and kdebluetooth only listen to later one, they won't find any devices in range. The Linux kernel and the tools from bluez-utils are capable of handling this. In fact they already handle the HCI_Extended_Inquiry_Response that will be introduced with Bluetooth 2.1.

The regression is that bluez-utils-2.x kept the Bluetooth 1.1 inquiry mode, while bluez-utils-3.x will use the best possible mode.

Comment 2 Bastien Nocera 2007-01-17 15:03:11 UTC
Any ideas how to fix it?
Comment 3 Kenny 2007-03-22 21:42:26 UTC
The best way is probably switch to using the D-Bus interface.

See the DiscoverDevices() method on the BlueZ wiki:
Comment 4 Bastien Nocera 2007-03-22 22:41:55 UTC
That's the plan, I've already made the changed to nautilus-sendto, if you're using that to send your files...
Comment 5 Mk.helldiver 2007-05-05 00:32:10 UTC
The Problem also exists under SusE Linux 10.2 with the latest bluez-libs + bluez-utils installed.

The gnome obex send GUI doesn't stop searching my mobile. 

But this evening I found a little cheat. Yust make a little script that calls 
"spdtool browse <mobiles mac>". When the obex send gui is searching too long again, run that script and the GUI finds the mobile. 
Comment 6 Bastien Nocera 2007-07-10 21:25:05 UTC
I believe this is fixed by this patch, which is now in libbtctl SVN trunk, and will be in libbtctl 0.9.

2007-07-10  Bastien Nocera  <>

        * src/btctl-discovery-source.c: (btctl_discovery_source_new):
        * src/btctl-discovery-test.c: (inquiry_result_with_rssi),
        * src/btctlimpl.c: (inquiry_result_with_rssi), (cb_hci_data):
        Patch from Marcel Holtmann <> to handle discoveries
        with RSSI info, as generated by newer bluez if the adapter supports it