Hmm, the dbus call is wrong:
method call sender=:1.200 -> dest=org.openobex.client serial=26 path=/; interface=org.openobex.Client; member=SendFiles
   array [
      dict entry(
         string "Destination"
         variant             string ""
      )
   ]
   array [
      string "/home/xslaby/txt"
   ]
   object path "/BlueDevil_sendAgent"


as opposed to gnome's:
method call sender=:1.203 -> dest=:1.185 serial=11 path=/; interface=org.openobex.Client; member=SendFiles
   array [
      dict entry(
         string "Destination"
         variant             string "00:24:7D:65:55:C5"
      )
   ]
   array [
      string "/home/xslaby/txt"
   ]
   object path "/org/bluez/agent/sendto"

Will try to fix before this weekend release.

I have been trying to reproduce this with no luck so far, is this 100% reproducible for you?

Are you able to apply some patches so we can get more debug info?

(In reply to comment #3)
> I have been trying to reproduce this with no luck so far, is this 100%
> reproducible for you?

Yeah.

> Are you able to apply some patches so we can get more debug info?

Sure.

Pushed some changes to bluedevil master, can you try again?

Setting it as needsinfo

Still no cookies with libbluedevil 1.9.3 and bluedvil 1.3.1:
method call sender=:1.97 -> dest=org.openobex.client serial=26 path=/; interface=org.openobex.Client; member=SendFiles
   array [
      dict entry(
         string "Destination"
         variant             string "00:24:7D:65:55:C5"
      )
   ]
   array [
      string "txt"
   ]
   object path "/BlueDevil_sendAgent"


gnome's sendto:
method call sender=:1.95 -> dest=:1.76 serial=11 path=/; interface=org.openobex.Client; member=SendFiles
   array [
      dict entry(
         string "Destination"
         variant             string "00:24:7D:65:55:C5"
      )
   ]
   array [
      string "/home/xslaby/txt"
   ]
   object path "/org/bluez/agent/sendto"



Note that you should pass an absolute path to openobex from bluedevil. But even if I try /home/xslaby/txt, the file is not delivered:
$ bluedevil-sendfile -f /home/xslaby/txt -k bluetooth://00:24:7D:65:55:C5 
bluedevilsendfile(13127) SendFileWizard::SendFileWizard: DeviceUbi:  "bluetooth://00:24:7D:65:55:C5"
bluedevilsendfile(13127) SendFileWizard::SendFileWizard: Files
bluedevilsendfile(13127) SendFileWizard::SendFileWizard: ("/home/xslaby/txt")
bluedevilsendfile(13127) SendFileWizard::SendFileWizard: DeviceUbi:  "bluetooth://00:24:7D:65:55:C5"
bluedevilsendfile(13127) SendFileWizard::SendFileWizard: Files
bluedevilsendfile(13127) SendFileWizard::SendFileWizard: ("/home/xslaby/txt")
bluedevilsendfile(13127) SendFileWizard::setDevice: "bluetooth://00:24:7D:65:55:C5"
bluedevilsendfile(13127) SendFileWizard::setFiles: ("/home/xslaby/txt")
bluedevilsendfile(13127) SendFilesJob::SendFilesJob: Adding size :  5
bluedevilsendfile(13127) KSharedUiServerProxy::KSharedUiServerProxy: kuiserver registered
bluedevilsendfile(13127) SendFilesJob::doStart:
bluedevilsendfile(13127) SendFilesJob::sendFileResult: Error:
bluedevilsendfile(13127) SendFilesJob::sendFileResult: "org.freedesktop.DBus.Error.NoReply"
bluedevilsendfile(13127) SendFilesJob::sendFileResult: "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."

I played with that a bit more. Sometimes, it works for a couple of times after I restart bluetoothd. Bluetooth might get into a bad state somehow or something...

(In reply to comment #8)
> I played with that a bit more. Sometimes, it works for a couple of times
> after I restart bluetoothd. Bluetooth might get into a bad state somehow or
> something...

I dag into that a bit more. It works until this is emitted by bluetoothd:
src/agent.c:agent_confirm_mode_change() Calling Agent.ConfirmModeChange: name=:1.14, path=/blueDevil_agent, mode=discoverable

This happens when I try to send a file after some idle time. When this occurs, the file is not sent and bluedevil times out.

Perhaps you do not service that signal while sending a file?

Created attachment 78917 [details]
patch

Perhaps this one :)?

(In reply to comment #10)
> Perhaps this one :)?

It's correct, but nobody tested that path obviously. It still doesn't work.

Maybe a single process is used for both this confirmation and send-file events?

You are completely right ! <facepalm>

None of the developers ever had to use bluedevil-confirmmodechange :/

Going to push your patch and make a release asap.
Does your patch fix this issue?
> (In reply to comment #10)
> > Perhaps this one :)?
> 
> It's correct, but nobody tested that path obviously. It still doesn't work.
> 
> Maybe a single process is used for both this confirmation and send-file
> events?

Oh, and sorry for the late deply :/

Git commit c59a99f425075277a4836b2ec8b0a410c67b69d6 by Àlex Fiestas.
Committed on 20/01/2014 at 02:20.
Pushed by afiestas into branch '1.3'.

Call the correct binary

M  +1    -1    src/daemon/kded/bluezagent.cpp

http://commits.kde.org/bluedevil/c59a99f425075277a4836b2ec8b0a410c67b69d6

So, this should be fixed in 1.3.3.