Bug 471313

The issue may not be with the PC having two separate networks, the problem may be a duplicate of bug 451154 instead.

(In reply to Pedro V from comment #1)
> The issue may not be with the PC having two separate networks, the problem
> may be a duplicate of bug 451154 instead.

Nope. That bug report says that it happens every time with hotspot. Hotspot works every time for me if I am only connected to the hotspot.

My problem appears only when the laptop is connected to two networks, ex. uni dorm room Ethernet cable and any WiFi router

I'm guessing that in both cases the issue is with broadcasting though, just not sure how would that happen in the hotspot case with just one interface. Maybe there are multiple interfaces in that case too even if they are not connected to the same network, or there are interfaces not considered by the users as they may not belong to physical connections.

Look at the findings I described in bug 470085 , you might have the same issue, and it's actually not hard to check, it's not even necessary to disconnect anything, the "Refresh" menu point on the phone side triggers discovery, so you can either:
- Just spam and see if you can see a connection on either side for a fraction of second
- Check the phone with logcat which is likely most feasible to use through adb
- Check the PC by (optionally?) killing kdeconnectd and running:
QT_LOGGING_RULES="*.debug=true; qt.*.debug=false" /usr/lib/x86_64-linux-gnu/libexec/kdeconnectd --replace

I'm suspecting all these issues to be related even if the hotspot one is not clear, but even there the remarks of adding by IP address suggests that skipping the broadcast discovery phase is what fixes the issue.

(In reply to Pedro V from comment #3)
> I'm guessing that in both cases the issue is with broadcasting though, just
> not sure how would that happen in the hotspot case with just one interface.
> Maybe there are multiple interfaces in that case too even if they are not
> connected to the same network, or there are interfaces not considered by the
> users as they may not belong to physical connections.

It clearly is an issue about broadcasting, and possibly just an issue about looking farther than the first network interface the computer connected to. As I said in the additional info part of my bug report, the problem is fixed if I disconnect the Ethernet, connect to the  routerx then restsrt kdeconnectd.

> Look at the findings I described in bug 470085 , you might have the same
> issue, and it's actually not hard to check, it's not even necessary to
> disconnect anything, the "Refresh" menu point on the phone side triggers
> discovery, so you can either:
> - Just spam and see if you can see a connection on either side for a
> fraction of second
> - Check the phone with logcat which is likely most feasible to use through
> adb
> - Check the PC by (optionally?) killing kdeconnectd and running:
> QT_LOGGING_RULES="*.debug=true; qt.*.debug=false"
> /usr/lib/x86_64-linux-gnu/libexec/kdeconnectd --replace
> 
> I'm suspecting all these issues to be related even if the hotspot one is not
> clear, but even there the remarks of adding by IP address suggests that
> skipping the broadcast discovery phase is what fixes the issue.

I'll try these when I get back home to my laptop, but, until then, could you point me to some documentation about android logcats? I have minimal ADB experience, none of which was related to logging/debugging android apps

The minimal adb experience should already cover the majority of needs as if adb is already working for you, then the logcat part should be trivial, but just to have everything for starting from scratch, here's what's needed to get the adb part covered:
https://developer.android.com/tools/adb#Enabling

Then logcat is really easy to deal with as there's even a dedicated adb command for it. I just went with the following to be able to handle all the output easily:
adb logcat | tee adb.log
This way you get to have a log file you can process more conveniently with your preferred text editor instead of looking around in the terminal which usually offers more limited ways to deal with the amount of text you'll get spammed with.

KDE Connect messages are apparently generally prefixed with "KDE/", and most messages about KDE Connect generally contain "org.kde.kdeconnect", although the later isn't that interesting in this case.

On the "KDE Connect Devices" screen there's a "Refresh" menu point which should trigger the issue conveniently without the need of fiddling with network connections. If you are affected by the same problem I've seen, then you'll see something like:
```
KDE/BackgroundService: onNetworkChange
KDE/LanLinkProvider: identity packet received from a TCP connection from [...]
KDE/LanLinkProvider: Starting SSL handshake with [...] trusted:true
LanLinkProvider: Starting handshake
KDE/LanLinkProvider: identity packet received from a TCP connection from [...]
KDE/LanLinkProvider: Starting SSL handshake with [...] trusted:true
KDE/LanLinkProvider: Handshake as client successful with [...] secured with TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
KDE/LanLinkProvider: Creating a new link for device [...]
updateDeviceInfo: Updating supported plugins according to new capabilities
LanLinkProvider: Starting handshake
```
Then later there should be quite noisy "Socket closed" and "Socket is closed" errors, but there's a whole lot more sign of life in-between confirming that things are getting fired up for real, even if not for long.
The point is to see whether the issue is the originally suspected "won't detect" problem, or it's really the stays connected only for a few milliseconds because of silly issues problem I'm seeing.