Controllers losing connection for a couple of seconds about xow HOT 30 CLOSED

@medusalix OK, so I performed some testing and I have good news. :)
Thread priority does not seem to be the cause. I tried boosting it and still got disconnects.
However, I tested reliability branch and played like 30 minutes without any problems.
I went back to master branch - instant disconnect on game launch.
Back to reliability - no issues at all. Tried changing locations in game to stress some CPU, still rock solid.
So, at least for my setup, you nailed it in reliability branch.

from xow.

Could you build a debug mode with more log if not already

You can run make BUILD=DEBUG to get a little bit of extra verbosity from xow. Logs are available via journalctl -u xow -b. Thanks for testing.

Looks like some kind of timeout-issue to me, when the CPU is so heavily used that it takes longer than normal for the xow driver to respond...

Could be. You could try giving the process a higher priority though.

I've made some general connection reliability/range improvements to xow (available in the reliability branch). There's a very small chance that these changes will affect this issue.

from xow.

Same here! Latest commit disconnects my controller for a second or two

from xow.

I can confirm this behaviour, going back to f06f669 makes it work flawless again.

edit
@zakaprov Are you sure it started with commit f06f669 for you? As for me that works fine, and only commit 50b46c4 gave me trouble. However, I do only have one gamepad, maybe it's related to having several of them.

from xow.

@NoXPhasma It's highly unlikely that 50b46c4 caused any connection problems. I'll have to investigate how the changes in f06f669 lead to the random disconnects.

from xow.

@NoXPhasma I'm sure about that, I encountered the problem before 50b46c4 was created.

from xow.

Alright, I was just curious as it seems not to happen for me with f06f669. At least not inside a time period of around one hour.

from xow.

I can't reproduce this issue with my 1708 controller and slim dongle. Left them connected for over 10 minutes and nothing happened. Commit f06f669 made some changes to the way disconnects are handled. Previous versions of the driver didn't detect when controllers got out of range (or somehow lost the connection). The driver just ignored the fact that these controllers were no longer sending any inputs. It must have something to do with that.

from xow.

@medusalix I have been seeing this as well with my RetroPi. We've seen this with two controllers connected while actively playing games, so it doesn't seem related to the controllers not sending any inputs or going out of range.

I haven't tested to see if it happens when only one controller is connected, but can test that as well if it would be helpful.

from xow.

Never had this issue until today.
Today this issue happened three times within only 1 hour to me after I had set the the steaming quality from "balanced" to "beautiful" (I am currently using the dongle on my Steam Link to stream the games from my Linux PC to my TV in the living room).
Possibly just a matter of coincidence, as I can think of no reason why the streaming quality could have an impact on this (I am using a wired Ethernet connection for streaming, no Wi-Fi). But after that I set the streaming quality back to "balanced", and played another 2 hours, without any issues.

from xow.

I confirm having this bug as well. I'm happy to help debugging if you need.

from xow.

But after that I set the streaming quality back to "balanced", and played another 2 hours, without any issues.

I don't think this is related. I'm seeing the same disconnection issue without steam being a factor at all.

from xow.

@medusalix I don't know if that helps but the issue doesn't seem to happen when the controller is idle / not being used.

from xow.

@medusalix I don't know if that helps but leaving the issue doesn't seem to happen when the controller is idle / not being used.
I can confirm this. only disconnects when using the controller

from xow.

I don't know if that helps but the issue doesn't seem to happen when the controller is idle / not being used.

That's definitely helpful, I'll look into it when I find the time.

from xow.

After checking out the previous commit (4edcee5) and reinstalling xow the issue is no longer present and controllers maintain a stable connection.

What's the proper way to revert to a previous version?
I tried:

git checkout 4edcee5
make BUILD=RELEASE
sudo make install
sudo systemctl enable xow
sudo systemctl start xow

but I am still experiencing the issue.

from xow.

Same here, and going back to the working commit simply prevented me to connect the controller at all (but I might be doing it wrong).

Really good job nonetheless, please send me a message if you want some info about my setup. I also confirm leaving the controller idle does not disconnect it, only while playing, which freezes old games, loses the mouse pointer and forces a restart :D

from xow.

Hey, I've got two things that might help me with this matter:

• What happens when you change the channel in the Makefile to something like 165 (or one of the other available channels)?
• Do the disconnects still happen when you get really close to the dongle with your controller?

from xow.

• The disconnects still happen regardless of the distance it seems
• They're not too bad when playing a modern game with auto reconnect
• Changing to channel 165 doesn't help, for me it disconnected at shorter intervals
• Could you build a debug mode with more log if not already, explain how to get systemctl logs, and add some more version and channel info into the startup logs so we can be sure we loaded the correct thing :)
• For some reason, I have to unplug/replug the dongle to make it work sometimes
• Here's a short session without changing the channel:

2020-02-24 22:13:10 INFO  - Dongle plugged in
2020-02-24 22:13:11 INFO  - Chip address: 62:45:b4:ea:a9:cf
2020-02-24 22:13:11 INFO  - Dongle initialized
2020-02-24 22:13:11 INFO  - Controller '1' connected
2020-02-24 22:19:34 INFO  - Controller '1' disconnected
2020-02-24 22:19:38 INFO  - Controller '1' connected
2020-02-24 22:25:47 INFO  - Controller '1' disconnected
2020-02-24 22:25:52 INFO  - Controller '1' connected
2020-02-24 22:28:47 INFO  - Controller '1' disconnected
2020-02-24 22:28:52 INFO  - Controller '1' connected

And after I switched to channel 165:

2020-02-24 22:32:15 INFO  - xow v0.3-20-g2d00485 ©Severin v. W.
2020-02-24 22:32:15 INFO  - Dongle plugged in
2020-02-24 22:32:15 INFO  - Chip address: 62:45:b4:ea:a9:cf
2020-02-24 22:32:15 INFO  - Dongle initialized
2020-02-24 22:32:22 INFO  - Controller '1' connected
2020-02-24 22:32:32 INFO  - Controller '1' disconnected
2020-02-24 22:32:36 INFO  - Controller '1' connected
2020-02-24 22:34:53 INFO  - Controller '1' disconnected
2020-02-24 22:34:58 INFO  - Controller '1' connected

from xow.

I'm observing frequents disconnects too, they happen so often the driver is not usable for me in current form.
I noticed disconnect happen on CPU spikes, for example: turning on Steam - disconnect and reconnect, turning on game - the same, game compiling shaders=stutters -> disconnect and reconnect.
In my short gameplay, controller got somehow reconnected as second controller making it impossible to play any longer.

lut 24 21:17:12 l0ud-pc xow[4209]: 2020-02-24 21:17:12 INFO  - Controller '1' connected
lut 24 21:17:14 l0ud-pc xow[4209]: 2020-02-24 21:17:14 INFO  - Controller '1' disconnected
lut 24 21:17:17 l0ud-pc xow[4209]: 2020-02-24 21:17:17 INFO  - Controller '1' connected
lut 24 21:18:08 l0ud-pc xow[4209]: 2020-02-24 21:18:08 INFO  - Controller '1' disconnected
lut 24 21:18:13 l0ud-pc xow[4209]: 2020-02-24 21:18:13 INFO  - Controller '1' connected
lut 24 21:19:34 l0ud-pc xow[4209]: 2020-02-24 21:19:34 INFO  - Controller '1' disconnected
lut 24 21:19:39 l0ud-pc xow[4209]: 2020-02-24 21:19:39 INFO  - Controller '1' connected
lut 24 21:19:40 l0ud-pc xow[4209]: 2020-02-24 21:19:40 INFO  - Controller '2' connected
lut 24 21:19:46 l0ud-pc xow[4209]: 2020-02-24 21:19:46 INFO  - Controller '1' disconnected

I suspect xow is not getting enough priority and is delaying some packet processing causing controller to be confused, but that's just a guess.

from xow.

@l0ud: So you have disconnects on CPU spikes, and I have disconnects on my Steam Link only when the streaming quality is set to "beautiful", not when it's set to "balanced". In other words: it does happen only when the Steam Link is heavily utilized, but not when it's partially idle...

Looks like some kind of timeout-issue to me, when the CPU is so heavily used that it takes longer than normal for the xow driver to respond...

from xow.

Can confirm, it's working for me to now.

from xow.

@medusalix I tested the version from reliability branch under very similar conditions as in my initial issue report (i.e. with two controllers used simultaneously to play). During the ~40 minute session I didn't encounter any problems, the connection on both controllers was solid.
Given the others' reports I'd say this resolves the issue and reliability can be merged into master. Thanks a lot for taking the time to fix this!

from xow.

Confirm, this is working perfectly now. I feel like windows. Is it because of the automated channel switching, you think ?

from xow.

Confirm, this is working perfectly now. I feel like windows. Is it because of the automated channel switching, you think ?

I'm really glad that it works 😄. I still need to do some testing before merging this into master. I'm not exactly sure what the code changes actually do in terms of the wireless connection and that's something I'd like to know first. If these changes actually enabled automated channel switching, then it is probably implemented in the firmware.

from xow.

Got it, that makes sense. The remark about merging was overly-enthusiastic on my part I guess. :D In any case, I'll keep running the driver off reliability branch for now. Is there any reason for you to think this affects the channels being used?

from xow.

What’s the proper way to install a new version of the driver? I am still experiencing issues after switching to reliability but I am not sure if I follow the proper process. Do I need to uninstall the previous driver first?

from xow.

@djibux You can check your xow logs to see which version you're currently running.
Assuming you're running the driver as a systemd service, this will give you the xow logs since last machine boot: sudo journalctl -u xow -b.
The first log line should include the version, e.g.: xow v0.3-9-g4edcee5. The tail of the version string includes the first few characters of the last commit hash it's using (in my example that's 4edcee5, exclude the g in the beginning). You can use it in GitHub's search to check which version of the program you're running.
As for installing the driver my usual routine goes something like this (assume running from xow's project directory):

sudo systemctl stop xow
make clean
sudo make install
sudo systemctl start xow

Uninstalling the driver first (sudo make uninstall) won't do harm, so I guess you can try that before re-installing. Good luck!

from xow.

Thanks, I will try that. I was not using make clean.

from xow.

Is there any reason for you to think this affects the channels being used?

Yes, definitely. The change that fixed this issue was most likely the introduction of channel candidates. The Windows driver goes through a bunch of channels on startup, taking measurements that probably decide whether that specific channels ends up in the list of candidates (xow uses a hardcoded list for now).
I've captured the wireless traffic and noticed that the dongle is now operating on channel 165 despite being set to channel 1 in the Makefile. I'm not 100% percent sure how the switching between the channels works, as the dongle always chooses the first channel of the candidates.
I think earlier versions of xow never unleashed the full wireless power that the dongle could operate with, because the controllers always lost the signal being a couple of meters away.

Anyways, the changes have been pushed into master. Thanks for your patience.

from xow.