blueman-sendto only works with --device option

[cschramm]

In Debian #812804 a user of 2.0.3 reports that using blueman-sendto with the --device option works, but he gets "Unable to find service record" if he does not provide the option but select the device in the GUI.

Not using the --device option will probably trigger a discovery, so I asked him to start a discovery manually and see if that breaks blueman-sendto --device as well, however I cannot believe that a discovery is actually harmful for that process. I have no other idea what could be different though and I cannot reproduce it...

[infirit]

I see the following in master when the device is not discovered. So you initial thought is correct 😄

We probably want to force the discovery, wait for it to be done, then attempt the transfer. If we then still can not get a proper object from dbus handle the TypeError.

$ blueman-sendto --device=6C:83:36:B9:C6:D6
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Traceback (most recent call last):
  File "/usr/bin/blueman-sendto", line 388, in <module>
    SendTo()
  File "/usr/bin/blueman-sendto", line 341, in __init__
    self.do_send()
  File "/usr/bin/blueman-sendto", line 350, in do_send
    sender = Sender(self.device, self.adapter, self.files)
  File "/usr/bin/blueman-sendto", line 132, in __init__
    print("Sending to", device['Address'])
TypeError: 'NoneType' object is not subscriptable

[infirit]

Wait, he is saying it is the other way around.. Let me go back and build the 2-0-stable branch.

[infirit]

I just pushed two commits, one from master and a new one, to the 2-0-stable branch that fix a couple of issues. I doubt it will fix his problem though but worth a try I guess.

After checking I also can not reproduce the problem. Device is properly discovered and I can send file to it. However there is the other error though that happens when we have a non discoverd device.

[cschramm]

Reporter Ralf Jung just confirmed that blueman-sendto --device during a discovery shows the same error. As we cannot reproduce it, I guess it's linked to a buggy controller. In any case it looks like we should not try to send a file during a discovery.

I'm not sure how to wait for a running discovery to end. We could use a blocking queue (while adapter.Discovering: time.sleep(3)) which is ugly or we could subscribe to the property-changed signal and wait for for Discovering to become False which has a crucial race condition (could become False between detecting True and subscribing to the signal; will wait for the signal forever).

The other question is if this is enough or if we would actually have to wait some time even after the discovery finished.

[infirit]

I would suggest we start a discovery unconditionally as we need to fix the other issue I got as well. DeviceList has a discovering attribute and a discovery-progress signal which we could use to check whether discovery stopped.

One option is to add a glib timeout that calls a function every half a second or so that check the Discovering property and starts the transfer when it stopped. Of course we can still have the user start a new discovery but there is no way we can code for that 😄

As for an additional delay, we can ask this user to do some experimenting. However I think it is not up to us to add any delays. If the adapter is buggy (hardware wise) the driver has to add some delay before notifying the world it is done.

[cschramm]

0951b20 is a patch for 2-0-stable. If you don't have anything to add, I'll ask the reporter to test if this solves his issue.

Regarding the issue you got, I'm not sure if I would consider that a bug / and issue. It does not make sense to set an unknown (i.e. neither discovered, nor paired) device as target, does it? If blueman-sendto is triggered by some other program, the device is probably known as the other program must have found the address somewhere. If blueman-sendto is triggered by the user or a custom script, he can pair the device and it should work whenever it's physically available.

[infirit]

I'm not sure if I would consider that a bug

It is a bug insofar that we do not handle this scenario. Other than that, I do not have strong opinion on it.

[cschramm]

The reporter confirmed the workaround fixes his issue. 😃

[RalfJung]

One thing I wondered... is there a way to cancel a running discovery? That's what I would expect to happen after selecting a device in the list, since it is obviously unnecessary to keep looking for other devices.

[cschramm]

Well, that would have made sense and been easier. 😆
2.0.4 is out with the fix, but I'll probably change it accordingly at least on master (which will be 2.1).