08-17-2016, 03:02 AM
08-17-2016, 04:05 AM
(08-17-2016, 03:02 AM)Jhonn Wrote: [ -> ]AFAIK the Dolphin Bar works only on 4.0-2241 or newer and at least with the v2 firmware update (or newer) MayFlash released at that time...
Those were the first things that I tried.
08-17-2016, 08:42 AM
(08-17-2016, 02:59 AM)FVGAZI Wrote: [ -> ]Correct. Worked last night perfectly. Then the same issue started again this morning. I actually have this same issue with my BT dongle, but I was assuming it was because it was a crappy BT dongle.
By issue do you mean it does work for some time, then spontaneously stops or it is not working at all from the beginning?
(08-17-2016, 02:59 AM)FVGAZI Wrote: [ -> ]Would love to know what your idea is.
As leolam said in the other Thread he had the same issue with his DolphinBar and Wiimote on Windows, whereas on Linux everything runs fine (i assume same system, as well as same Dolphin Version).
Additionally Caturix did run my test program and that was working with his Wiimote and DolphinBar. So it seems to be an issue somewhere in the Windows LL Wiimote implementation.
The main difference between Linux and Windows is that on Windows the "ReadFile"-Calls always report back 22 Bytes of data. If the report is less than 22 bytes the remaining ones contain old data from previous bigger reports or garbage if those bytes were never used. So we have a buffer that is too big in its actual size and contains random data. That kind of screams for random weird behavior.
However that's regardless of how the Wiimote is connected (Bluetooth or DolphinBar). So there should be other reports of knockoff and original Wiimotes not working via BT and DolphinBar when that is the cause.
One explanation why it only affects the DolphinBar may that it continuously sends Reports regardless of the Reporting Mode. It literally spams them, which in turn only then causes the bug.
Anyway that is just a very rough and wild guess. Without the ability to reproduce that behavior i can't say anything for sure.
08-17-2016, 09:22 AM
(08-17-2016, 08:42 AM)JulianLoehr Wrote: [ -> ]By issue do you mean it does work for some time, then spontaneously stops or it is not working at all from the beginning?
As leolam said in the other Thread he had the same issue with his DolphinBar and Wiimote on Windows, whereas on Linux everything runs fine (i assume same system, as well as same Dolphin Version).
Additionally Caturix did run my test program and that was working with his Wiimote and DolphinBar. So it seems to be an issue somewhere in the Windows LL Wiimote implementation.
The main difference between Linux and Windows is that on Windows the "ReadFile"-Calls always report back 22 Bytes of data. If the report is less than 22 bytes the remaining ones contain old data from previous bigger reports or garbage if those bytes were never used. So we have a buffer that is too big in its actual size and contains random data. That kind of screams for random weird behavior.
However that's regardless of how the Wiimote is connected (Bluetooth or DolphinBar). So there should be other reports of knockoff and original Wiimotes not working via BT and DolphinBar when that is the cause.
One explanation why it only affects the DolphinBar may that it continuously sends Reports regardless of the Reporting Mode. It literally spams them, which in turn only then causes the bug.
Anyway that is just a very rough and wild guess. Without the ability to reproduce that behavior i can't say anything for sure.
We've been playing off the BT dongle most of the afternoon without any major issues. I did have a few random drops, but the continuous setting seems to lock right back on to the Wiimotes.
Just found your program. Haven't read everything on the page yet, but is this something you'd suggest I try?
08-17-2016, 09:14 PM
It's no "fixing" tool, so it won't help with the issue. It is just a small diagnostics tool, that is a stripped down version of how Dolphin uses the Windows HIDAPI to communicate with the Wiimote. Therefore it just tells me whether there is something wrong with the HID Stack and usage of its API or Dolphin messes up somewhere else.
08-18-2016, 12:51 AM
(08-17-2016, 09:14 PM)JulianLoehr Wrote: [ -> ]It's no "fixing" tool, so it won't help with the issue. It is just a small diagnostics tool, that is a stripped down version of how Dolphin uses the Windows HIDAPI to communicate with the Wiimote. Therefore it just tells me whether there is something wrong with the HID Stack and usage of its API or Dolphin messes up somewhere else.
I read into the other thread more and figured that out.
I should say that my problem is only occurring during gameplay with multiple Wiimotes connected. I never have an issue with single player. Two player works ok 90% of the time with a cheap BT dongle, but as soon as I connect 3... game over for one of the controllers.
The Dolphinbar can't seem to handle two player for more than a minute. One will work ok with no problem. 3 never works for more than a second.
The other thing I haven't said is that when a controller drops on the DB it(wiimote) flashes a disconnect/sync lights, then will reconnect to the DB and buttons don't work in game. I can add/drop player from the in game menu(NSMB) then re-add same player and the same Wiimote that previously stopped working works again for a short time.
Is multiplayer semi-functional in Dolphin? I've only played games single player through Dolphin until recently and multiplayer just seems to be horrible. I guess I could hook up a Wii to my TV, but Dolphin looks really good in 4K.
08-18-2016, 10:50 AM
So here is the PR/Build with the possible fix: https://buildbot.dolphin-emu.org/builders/pr-win-x64/builds/2449 (Direct DL-Link: http://dl.dolphin-emu.org/prs/pr-4128-dolphin-latest-x64.7z).
Any feedback is appreciated.
While testing my fix i encountered your problem as well, FVGAZI. I used a single non-TR Wiimote and at certain points it would sometimes disconnect (Event Viewer: "Bluetooth HID device either went out of range or became unresponsive."). When reconnecting it right away, it would immediately disconnect again. Only stopping the game, connecting the Wiimote and then starting the game again would allow it remain connected (until the next random disconnect). However i was not able to find a safe way to reproduce it. So it seems there is indeed some black magic going on.
I used my test program generate alot of traffic (enabling continuous reporting, as well as requesting status reports and sending some memory write report) and while the non-TR Wiimote did run fine for minutes, a TR-Wiimote would disconnect within a minute.
Any feedback is appreciated.
While testing my fix i encountered your problem as well, FVGAZI. I used a single non-TR Wiimote and at certain points it would sometimes disconnect (Event Viewer: "Bluetooth HID device either went out of range or became unresponsive."). When reconnecting it right away, it would immediately disconnect again. Only stopping the game, connecting the Wiimote and then starting the game again would allow it remain connected (until the next random disconnect). However i was not able to find a safe way to reproduce it. So it seems there is indeed some black magic going on.
I used my test program generate alot of traffic (enabling continuous reporting, as well as requesting status reports and sending some memory write report) and while the non-TR Wiimote did run fine for minutes, a TR-Wiimote would disconnect within a minute.
08-18-2016, 02:47 PM
(08-18-2016, 10:50 AM)JulianLoehr Wrote: [ -> ]So here is the PR/Build with the possible fix: https://buildbot.dolphin-emu.org/builders/pr-win-x64/builds/2449 (Direct DL-Link: http://dl.dolphin-emu.org/prs/pr-4128-dolphin-latest-x64.7z).
Any feedback is appreciated.
While testing my fix i encountered your problem as well, FVGAZI. I used a single non-TR Wiimote and at certain points it would sometimes disconnect (Event Viewer: "Bluetooth HID device either went out of range or became unresponsive."). When reconnecting it right away, it would immediately disconnect again. Only stopping the game, connecting the Wiimote and then starting the game again would allow it remain connected (until the next random disconnect). However i was not able to find a safe way to reproduce it. So it seems there is indeed some black magic going on.
I used my test program generate alot of traffic (enabling continuous reporting, as well as requesting status reports and sending some memory write report) and while the non-TR Wiimote did run fine for minutes, a TR-Wiimote would disconnect within a minute.
Ok. I'll download it and give it a shot then let you know how it goes.
I definitely appreciate you taking the time to help me out with this.
My 3 yr old daughter has recently discovered Mario and we've been playing non-stop.
I actually started using an Xbox one controller with it's wireless adapter as the second controller. No problems whatsoever.
08-18-2016, 10:21 PM
(08-18-2016, 02:47 PM)FVGAZI Wrote: [ -> ]Ok. I'll download it and give it a shot then let you know how it goes.
I definitely appreciate you taking the time to help me out with this.
My 3 yr old daughter has recently discovered Mario and we've been playing non-stop.
I actually started using an Xbox one controller with it's wireless adapter as the second controller. No problems whatsoever.
Ok, can you also enable the Log and check it for any lines other than "Error on WriteFile" (Set Log Verbosity to "Warning" and only check the "Wiimote" Log Type).
When i finally implement the Dolphin Mode for my driver, i will try to find out more on that BT Dongle Disconnect issue.