search

GSConnect / gnome-shell-extension-gsconnect

KDE Connect implementation for GNOME
GNU General Public License v2.0
3.22k stars 259 forks source link

"Waiting for Service..." #887

Closed AlbinoGeek closed 4 years ago

AlbinoGeek commented 4 years ago

Describe the bug

Doesn't work out of the box.

Steps To Reproduce:

  1. Install GSConnect on Desktop
  2. Install KDE Connect on Android
  3. Open GSConnect on Desktop
  4. Add Desktop's IP in KDE Connect... still doesn't show.
  5. Add Android's IP in "Connect to..." in GSConnect... still doesn't show.
  6. Click refresh repeatedly in GSConnect... nothing happens.
  7. Click refresh repeatedly in KDE Connect... nothing happens.

Expected behavior

Anything other than nothing.

Screenshots

image

Support Log

GSConnect Version: 39
GSConnect Install: user
GJS: 16403
XDG_SESSION_TYPE: x11
GDMSESSION: gnome
--------------------------------------------------------------------------------
-- Logs begin at Sat 2019-10-12 21:11:21 PDT, end at Tue 2020-06-30 08:50:11 PDT. --
-- No entries --

System Details (please complete the following information):

GSConnect environment (if applicable):

rohmishra commented 4 years ago

Hey, i noticed you have access to two mobile devices (Pixel 2 and Galaxy S20+). Are you able to connect to one phone from another?

andyholmes commented 4 years ago

Can you please follow the steps for Generating a Support Log as described in the Wiki?

AlbinoGeek commented 4 years ago

@rohmishra "Connect to one phone from another"?

They do not show up in KDE Connect if that's what you're asking,

@andyholmes I did, and it's an empty log (as attached above.) I repeated all my steps while that dialogue was open, shown below:

itsagif

Note that the only three lines shown in the log were triggered by my screen recorder [peek] and literally ping.

GSConnect Version: 39
GSConnect Install: user
GJS: 16403
XDG_SESSION_TYPE: x11
GDMSESSION: gnome
--------------------------------------------------------------------------------
-- Logs begin at Sat 2019-10-12 21:11:21 PDT, end at Tue 2020-06-30 13:11:28 PDT. --
Jun 30 13:11:18 gnome-shell[3215]: Recording to /home/damon/.cache/peek/peekTPKPM0.mp4
Jun 30 13:11:25 ModemManager[890]: <warn>  (tty/ttyACM0) at port timed out 3 consecutive times
Jun 30 13:11:28 ModemManager[890]: <warn>  (tty/ttyACM0) at port timed out 4 consecutive times
AlbinoGeek commented 4 years ago

For completionist sake:

The gif above is the process on the Samsung Galaxy S20+ 5G as remoted through scrcpy I have repeated the process using my Google Pixel 2 and the same lack of results are shown.

The Trusted Networks section of KDE Connect has Allow all checked.

image

rohmishra commented 4 years ago

Hmm... that's quite weird I'll have to dig up my old phone to confirm if this is still the case even now but last time I tried, the phones were able to connect to each other.

Is it possible to try starting a hotspot on one of the phones, and then connecting to the phone on the hotspot?

I myself use a pixel and have helped a friend set up his galaxy S8 and the default firmware just works for me.

Is your computer connected via wifi or through ethernet?

Is device isolation disabled on your router/AP?

andyholmes commented 4 years ago

Because the message in the window is "Waiting for service...", we know that the GSConnect service is not running, so trying to connect from a remote device definitely won't work. Trying to connect to a remote device should start the service automatically.

So, what we're looking for is the reason the service is not starting. I'm assuming you've checked that extensions are enabled in gnome-extensions-app/gnome-tweaks, and that you haven't turned off the service in the User Menu.

Since trying to connect via the Preferences didn't work, you will probably have to run the service manually to see the startup error:

$ cd ~/.local/share/gnome-shell/extensions/gsconnect@andyholmes.github.io/service
$ ./daemon.js
AlbinoGeek commented 4 years ago

@rohmishra I can confirm the issue has nothing to do with the network setup because...

@andyholmes Running the service manually resulted in the following output:

(GSConnect:3580733): GLib-CRITICAL **: 15:27:43.809: g_variant_new_string: assertion 'string != NULL' failed
(GSConnect:3580733): Gvc-CRITICAL **: 15:27:43.820: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed
(GSConnect:3580733): Gvc-CRITICAL **: 15:27:43.820: gvc_mixer_card_get_index: assertion 'GVC_IS_MIXER_CARD (card)' failed

Which then had my device show up within the software after pressing refresh 1-2 times, then waiting ~10 seconds. The following output was generated after pairing with the device:

Gjs-Message: 15:28:19.752: JS WARNING: [/home/damon/.local/share/gnome-shell/extensions/gsconnect@andyholmes.github.io/service/protocol/lan.js 715]: reference to undefined property "GSocketOutputStream"

At this point, the bug is now in regards to the service not being automatically started, and requiring a manual start.

For troubleshooting sake:

All of which do not result in the service being started, I must start it manually by way of the command you have supplied.

andyholmes commented 4 years ago

Can you confirm that trying to start the service from the User Menu (top-right of the panel) also does not work?

For context, here's how it generally works:

So assuming the service is enabled, the problem is probably related to DBus activation. In that case, you'll want to try to start the service via DBus and check the system log to find out what the error is. The easiest way to do this is:

$ gapplication launch org.gnome.Shell.Extensions.GSConnect
AlbinoGeek commented 4 years ago

@andyholmes

Peek 2020-07-03 22-23

Pressing "Refresh" in the window also does nothing.

Peek 2020-07-03 22-28

As per the supplied command:

[damon@doom service]$ gapplication launch org.gnome.Shell.Extensions.GSConnect
error sending Activate message to application: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable

Perhaps this is the issue?

andyholmes commented 4 years ago

Ah, now this rings a bell. There is an issue sometimes with dbus-broker which is usually fixable with:

​$ systemctl reload --user dbus-broker.service

Let me know if that fixes it, and I'll add a wiki note because I keep forgetting about this. I think I've debugged this same issue with people about 6 times 🤔

theotheroracle commented 4 years ago 
​$ systemctl reload --user dbus-broker.service

Let me know if that fixes it

it does fix it for me actually .

andyholmes commented 4 years ago

@theotheroracle thanks for reporting, as an aside are you also running Fedora? If so this might be an upstream bug in their systemd package I should report, since I don't recall anyone on other distros reporting it.

I'll try to remember to update the wiki with this as a 1st step before reporting and issue, and close the bug if @AlbinoGeek can confirm this works for them as well.

theotheroracle commented 4 years ago

yeah, i'm on fedora .

ferdnyc commented 4 years ago

Stab taken at updating the "Watiing for Service" troubleshooting section of the wiki.

andyholmes commented 4 years ago

Stab taken at updating the "Watiing for Service" troubleshooting section of the wiki.

Perfect! I like it covers ensuring that's the actual problem, in case there's some other reason this might happen.

ferdnyc commented 4 years ago

@andyholmes Yeah, that's my phobia about cargo cult troubleshooting at work.

Too often, something works once, so people just start doing it by rote — whether it makes sense or not.

If we just posted "try resetting dbus-broker" and left it at that, the bug that causes the problem could be fixed tomorrow, but three years from now we'd still have users resetting it every time there's any problem with GSConnect. Because hey, it worked that one time! 😆

akitakedits commented 4 years ago

Same issue on Fedora. Reloading dbus-broker.service fixes it.

andyholmes commented 4 years ago

Closing since this is an upstream bug and we've got it covered in the Wiki now.