Fine that someone can confirm that, when I packaged gnome-user-share 2 days ago for ubuntu I was not able to push files; I wasn't sure if it was due to my setup.

I have to add that I am using ubuntu too, so it could be related to a bug in the bluez base packages, not sure. But the fact that the ods test server works totally fine indicates that not much can be wrong below in the stack, so my guess would be g-u-s not supporting the current bluez 4.12 or ods api correctly. 

You need to use the current trunk of gnome-user-share to start with. Is your phone a Nokia Series 40 phone?

Micheal,

Could you try the version 0.40 in my ppa (https://launchpad.net/~bmillemathias/+archive), and get back to me?

0.40 won't work with bluez 4.x. You need gnome-user-share trunk.

Yes I had g-u-s trunk (with "Port to the BlueZ 4.x API").

I tested with a nokia 6300 (s40, right). But I just also tested with my SE k750i. The phone seems to completely lock up when trying to establish the connection, even the off switch does no longer work

Could you test with obex-data-server's test program, like so:
./ods-server-test.py --ask-to-accept opp /tmp/

It should hang the same way...

Right, hangs the same, like this:

$ ./ods-server-test.py --ask-to-accept opp /tmp/
Server object:  /org/openobex/server0
Started
Session created: /org/openobex/serversession0
Session Bluetooth address: 00:1C:D6:86:B1:4C

Without the --ask-to-accept it works fine.

Closing as a bug in obex-data-server:
http://bugs.muiline.com/view.php?id=140

Michael, as you can reproduce the issue, could you monitor the issue there as well, and eventually answer Tadas' questions?

Sure. Thanks a lot.

Since no one reacted to my comment in ods bug tracker, I'm just copying it here:

Sorry, but I can't make any sense from this bug. I need more information. The only code that acts differently according to auto_accept setting is just a few lines. Before that, there should be "suspending request" message in ods output. Without ods output I can't really do anything since this stuff works for me.

So what I need you to do is:
1) run ./obex-data-server --no-daemon
2) run ./ods-server-test.py --ask-to-accept opp /tmp
3) start sending file from phone
4) post me output of obex-data-server and ods-server-test.py when it hangs. Ideally, you could also run obex-data-server with gdb and see at which place in code it actually hangs.

Logs attached to the ods bug now. Sorry, I did not get any status change mail so I didn't notice you replied.

BTW, you have to choose "Monitor issue" to get updates in Mantis bug tracker.

A fix for this bug is in ods svn rev 2102.

I added a timeout between emitting Server.SessionCreated and ServerSession.TransferStarted. The current timeout is set to 250 milliseconds. Please check if this is sufficient.

I just tested r2103 and it's still the same for me (stuck at 11%)

I'd certainly rather see a proper fix that requires API changes rather than a hack with a timeout...

Created attachment 121225 [details] [review]
patch for testing

Apply this patch and post ods output again.
I hope this timeout hack is temporary until I figure out how to properly update API. Feel free to suggest a solution.

Tested... going up to 16% but not further, even after waiting a very long time, sorry.

Please post ods output when running with that patch applied.

Created attachment 121329 [details]
New Log

Here's a log where it hangs at 14%. Seems to depend on the file size but for photos it always seems to be the 10%-15% region.

Check if it works with newest ods svn. I think I found why TransferStarted signal wasn't emitted correctly.

>>/org/openobex/serversession0<<  -- RemoteFilename = Image001.jpg
Accept file? Type 'a' to accept, 'r' to reject:
>>> a
Accepting
>>/org/openobex/serversession0<<  Progress: 0 %
>>/org/openobex/serversession0<<  Progress: 16 %
>>/org/openobex/serversession0<<  Progress: 33 %
>>/org/openobex/serversession0<<  Progress: 49 %
>>/org/openobex/serversession0<<  Progress: 66 %
>>/org/openobex/serversession0<<  Progress: 82 %
>>/org/openobex/serversession0<<  Progress: 99 %
>>/org/openobex/serversession0<<  Transfer completed
>>/org/openobex/serversession0<<  Disconnected

It now asks if I want to accept (phone hangs at 16%) but completes the transfer as soon as I hit a! :)

Trying again with gnome-user-share, my phone does not detect the "server". Perhaps the g-u-s needs to be adapted to the newest o-d-s?

This means that it finally works ! Yay. You can try running ods with --no-daemon and look if g-u-s actually starts the server.

Heh strange... If I kill all obs processes, start gnome-file-share-properties, enable the checkbox and close the window it starts an obs process but the phone does not find anything. If I now start gnome-file-share-properties again, turn the checkbox off and on again it works fine.

Also, enabling the pref if I have started obs manually works right away.

Do you have ods svn installed in you system? because when g-u-s auto-starts ods, it starts /usr/bin/obex-data-server. You might have some older ods version installed in you system. Just guessing here..

No, I already checked this. My obs trunk is installed in /opt/gnome2.24 alongside the rest of GNOME and there's no distribution-supplied old version in /usr.

Tadas, will you be making a new release, or should I extract the patch from SVN?

I will make release today or tommorow.

Hi, I'm testing Fedora 10 and I have probably the same issue.

I have LG KU990 mobile phone and I try to send picture over bluetooth to my laptop running Fedora 10 and it fails. I have bonded the LG KU990 to laptop over bluetooth but I still can't send files over BT to laptop.

I tried to send files with Sony Ericsson K750 and that works ok even if the phone isn't bonded.

How can I troubleshoot this more? Is there some list of which mobile phones work and which don't work with bluez?

hope these additional information help:

# rpm -qa "*bluez*" obex-data-server gnome-user-share
obex-data-server-0.4-1.fc10.i386
gnome-user-share-0.40-3.fc10.i386
bluez-gnome-1.8-7.fc10.i386
bluez-libs-4.16-1.fc10.i386
bluez-cups-4.16-1.fc10.i386
bluez-alsa-4.16-1.fc10.i386
bluez-4.16-1.fc10.i386


$ gconftool-2 -R /desktop/gnome/file_sharing
 bluetooth_obexpush_enabled = true
 require_password = never
 bluetooth_accept_files = always
 bluetooth_enabled = false
 bluetooth_notify = true
 enabled = false
 bluetooth_allow_write = false
 bluetooth_require_pairing = true

Released obex-data-server 0.4.1 which fixes this problem.

I killed obex-data-server and then started it with "obex-data-server -n"
Then I started obex test server with:
python /usr/share/doc/obex-data-server-0.4/ods-server-test.py --ask-to-accept opp /tmp/

Then I tried to send the image again from LG phone to laptop

obex-data-server showed this as output:

** Message: obex-data-server 0.4
** Message: Using Session bus
** Message: server socket created
** Message: Server created by: :1.92

** (obex-data-server:3504): WARNING **: Server path: /tmp/
** Message: Client connecting
** Message: Creating server session

** (obex-data-server:3504): WARNING **: Session path: /tmp/
** Message: Bluetooth address: 00:1E:75:00:00:00
** Message: io callback
** Message: event: 1
** Message: event: 2
** Message: CMD_CONNECT requested
** Message: Version: 0x10. Flags: 0x00  OBEX packet length: 4266

** Message: Resizing stream chunks to 4066

** Message: event: 3
** Message: io callback
** Message: event: 1
** Message: event: 11
** Message: CMD_PUT requested at REQCHECK
** Message: header: 195
** Message: HDR_LENGTH: 469059
** Message: header: 1
** Message: HDR_NAME: P050908_23.11[01].JPG
** Message: path: /tmp/
** Message: ret=0
** Message: event: 0
** Message: io callback
** Message: io callback
** Message: io callback
** Message: io callback
** Message: io callback
** Message: io callback
** Message: io callback
** Message: io callback
** Message: io callback
** Message: io callback
** Message: io callback
** Message: io callback
** Message: io callback
** Message: event: 9
** Message: suspending request

Great news Tadas, I'll test it as soon as it comes to Fedora 10.

Works great! Thank you.