"Leap Motion Controller is off" - Cannot resume tracking after v1.2 update

[pip25]

I updated to the latest 1.2 software today, and since then I couldn't get Leap to work. All apps show it as disconnected, the control panel reports that it is "off", but the "Resume Tracking" option, suggested as a temporary measure in other threads, does not do anything in my case. I tried restarting the service, and later tried reinstalling the driver using the latest binary from leapmotion.com's download page, but nothing helped. The software log window is completely empty.
As an interesting side-effect, the control panel application now forces me to accept the "End User License Agreement" each time it is started. If it matters, I did not have the control panel application set to autostart, so I might have missed an update or two before.
Any help from the devs would be greatly appreciated.

Edit: My system runs Windows 7 (32 bit).

[jdonald]

That last issue sounds like a permissions issue with the EULA acceptance marker.

What files are in your %AppData%\Leap Motion folder? Is there a eula* file in it? Try removing the folder (well, make a backup first). From then on it'll hopefully allow you to accept the EULA and make it stick.

If that doesn't solve the "Leap Motion Controller is off" problem, then it's possible you're seeing something similar to the unexplained issue encountered by twf1985.

For the empty software log, it's unfortunate that not all of the service output messages show there. You can debug like so :

If there are errors at service startup, unfortunately today many of those don't show in the GUI software log. You can get more debug output by stopping the service (services.msc, right-click Leap Service, Stop), and opening up a command prompt to C:\Program Files (x86)\Leap Motion\Core Services to run LeapSvc.exe --run

After trying that out, be sure to start the service again to get things back to your base state as we continue to troubleshoot.

[pip25]

Thanks for the tips, unfortunately none of them seems to have worked.
The %AppData%\Leap Motion folder was indeed missing any eula* files, but removing it made no difference: the folder was re-created, and a new config.json and a file named tt.xml was put in it, but no eula* file of any kind.
If this is about a missing file, can't this possibly be a path encoding problem though? My username has special characters ("á" and "é" specifically) in it, and a few software did have problems with that in the past, even though Leap Motion worked fine so far. Unfortunately, I am not in a position to change my username or system users to try this out.
The issue linked seems to start with certain error messages during update/install, but I experienced none of those; my update and later the reinstall both ran without errors, or at least without any error that would create such a user prompt.
Lastly, I ran the service from the command line as you asked, and it produced the following output in the CMD window:
[09:32:16] [Info] WebSocket server started
Meanwhile, the software log when accessed from the UI now contains this:
[09:33:46] [Info] Tracking resumed
[09:33:46] [Info] Tracking paused
I think that was one of my attempts at resuming the tracking functionality. As you can see, some "mysterious force" appears to have paused tracking immediately afterwards. Choosing "Resume tracking" again seems to have no effect on the log anymore. I restarted the Control Panel app and tried resuming multiple times, but no other output was written to the CMD window or the UI log.
Thanks again for your help.

Edit: It would seem that I can re-create the "Tracking resumed - Tracking paused" log entry by restarting the service itself and choosing "Resume tracking". Only once per service restart though.

[jdonald]

I created a user with characters such as áéíóú to try this out. Indeed, it fails to write files such as lastauth (turns out we no longer use eulahash.md5). Thus, you end up having to accept the EULA multiple times. We'll look into this.

On the bright side this probably isn't related to your 'Tracking paused' problem. Even if I have to accept the EULA multiple times, I can still use my device with the Visualizer. I think this problem is similar to what was seen by twf1985 (linked earlier) and FlemmingH, a regression in version 1.2 that we're looking into.

Given the similar symptoms, I'd like you to first confirm that the problem goes away when you downgrade to 1.1.3 (note: can do this with the Leap Motion Controller, but not the HP embedded Leap Motion controllers).

Next, we'd still like to get the latest software working. Once you reinstall version 1.2, try ruling out the WinUSB driver. Open up Device Manage -> Universal Serial Bus devices -> Leap Motion Controller -> right-click -> Uninstall -> check Delete the driver software for this device. Then unplug your controller and reboot. This will get the software to fall back to DirectShow mode similar to version 1.0.9.

And if this experiment doesn't help, you can reinstall the driver by going to C:\Program Files (x86)\Leap Motion\Core Services\Drivers and running dpinst64.exe, or just reinstall the software entirely.

[pip25]

Thanks for looking into this.

Strangely enough, the 1.1.3 installer greeted me with a #{DESC_BelowSpecMsg} message (or something very close to it; I forgot to take a screenshot, sorry about that), but once I chose "ignore" it installed without difficulty and the Leap worked perfectly once again. I now recall that it did a similar thing when I first installed this version, but showed no problems afterwards, which is probably why I forgot about it until now. I'm not sure what this missing message resource might indicate, by the way, but I highly doubt my i7 machine is below the minimum specs.

I then ran the update through the control panel application which returned me to the previous broken state, after which I uninstalled the controller's driver as you requested. After reconnecting the Leap, it now showed up among "imaging devices" (or similar, my Windows is not set to English) in the Device Manager, so I would say that the driver fallback did in fact occur. However, the symptoms remained unchanged: the Leap still appeared to be off, and the attempt to resume tracking was fruitless.

[jdonald]

So it sounds like version 1.1.3 still works properly (other than that unwelcome dialog upon installation).

Your ${DESC_BelowSpecMsg} printout was a known double-bug in version 1.1.3. Because you have installed a 32-bit operating system on a 64-bit processor the software gets confused. This was fixed in version 1.2.

Thanks for ruling out the WinUSB driver. That was worth a shot, but now we'll try to think of something else.

[jdonald]

Okay, "tracking paused" in the software log can mean the device is disconnected for any reason: Pulled the plug, USB traffic errors, or some issue causing a disconnection in version 1.2.0 of the software.

Next steps are to identify whether the device is detected, whether it is ever streaming, and if it is communicating with the Leap Motion Control Panel.

So with version 1.2.0 (WinUSB driver enabled and all), could you run the service from the console again? That is, stop the Leap Service in services.msc, then go to C:\Program Files (x86)\Leap Motion\Core Services and run LeapSvc.exe --run from a command prompt. Also, leave the Leap Motion Control Panel open with the "Show Software Log" window while viewing this.

Last time I know you got the useless "WebSocket server started, Tracking resumed, Tracking paused". In version 1.2.0 it's possible for the service to detect a device and unpause it even when tracking has been paused, so let's try that. If you unplug and reconnect your device across different USB ports, do you see more information in the console and the software log?

On my machine I see prints like so from the LeapSvc.exe console :

[15:25:29] [Info] WebSocket server started
[15:25:29] [Info] Initializing WinUSB
[15:25:29] [Info] Initialized WinUSB
[15:25:29] [Info] Leap Motion Controller detected: LP
[15:25:29] [Info] Firmware version: 17
[15:25:29] [Info] Firmware is up to date.
[15:25:29] [Info] Processing initialized
[15:25:33] [Info] Reversed tracking orientation
[15:25:35] [Critical] Could not obtain information about a completed frame
[15:25:35] [Info] Tearing down WinUSB
[15:25:35] [Info] Leap Motion Controller disconnected: LP

If you see no messages other than the three you originally saw, then the device is not even getting detected. If you see messages but any detected device gets followed by an unwelcome "Tracking paused", then we know the device is getting detected but then disconnected. And if we see positive messages on the console but not in Leap Motion Software Log, then we can suspect a service<->client communication problem.

Thanks so much for your help so far in tracking this down.

[pip25]

All right, now this is simply bizarre: I reinstalled the 1.2.0 drivers again, restarted the service from the command line, got nothing but the previous websocket and resume/pause messages.
Then I unplugged the cable at the end where it connects to my desktop (so far I only disconnected at the Leap's end), plugged it into a different port, and it suddenly started to work! My PC has a mixture of USB 2.0 and 3.0 ports, but I believe both ports I tried here (both the original and the new one) were USB 2.0 (or not, see edits). That's not all though! After re-plugging the Leap to its original port, the device is still working! In fact, at the moment I simply cannot find a way to reproduce the bug at all. (Restarting the service the normal non-command-line way made no difference.) Considering this error condition survived PC restarts previously, I don't have the faintest idea how is this even possible... O_o

EDIT: I managed to reproduce the bug again by plugging the Leap into one of the USB 3.0 ports. My USB 3.0 ports were never very friendly with non-storage devices though, probably because of chipset driver issues.

EDIT 2: The Leap works with the older 1.1.3 driver even when plugged into my USB 3.0 port. Maybe I was wrong, and despite my previous convictions it was originally plugged there? Frankly, it's such a cable jungle back there and those ports are close enough to each other that I cannot rule out that I made a mistake with my previous test.

EDIT 3: Since it seems to play a role here, here are the specs of my motherboard:

http://www.asrock.com/mb/Intel/Z68%20Extreme4/?cat=Specifications

It uses an Etron EJ168A host controller for USB 3.0, since this is a Sandy Bridge board which lacks USB 3.0 support by default.

[sjmorrison]

First post here, be gentle with me
I've been having the same problem on my own system. I have a Sandybridge board with the same Etron USB 3.0 controller. I just moved the Leap controller from that to a USB 2.0 port and bingo, now working with the new version of the drivers. I also noticed that the controller now identifies itself as Leap Motion rather than a generic USB device.
Thanks for the info pip25
Cheers

Scott

[pip25]

Well, I'm happy to have helped others, but this thread has gone awfully quiet all of a sudden. I'm well aware that the Leap devs can't support every possible chipset configuration, but the fact that a driver update broke one that was already working should be considered a bug, don't you think...?

[swoo]

I have also had issues with an Etron host controller using their latest drivers (version 1.0.0.118). When I rolled back to the previous driver (6.2.9200.16656), my Leap device worked fine.

[pip25]

That's rather odd, since I was testing with a pretty old Etron driver at first, before I updated to the latest version supported by my motherboard's manufacturer (1.0.0.115), and neither of them worked. Could you give me a download link to that particular version? I would like to give it a try as well.
EDIT: Also, it's worth noting that the previous version of the Leap driver worked with all the Etron USB drivers that I've tried.

[swoo]

I'm having trouble finding that version online too. Do you know what version you had before updating?

[pip25]

Something around 0.96_WHQL, maybe? Downright ancient, I'd say. From what little info I found about version 6.2.9200.16656 with Google, your driver does not seem that old, as it came out a year ago or so (0.96_WHQL on the other hand is from 2011).

[jdonald]

Was able to debug this after reproducing the problem on my own desktop with the Etron USB3 Host Controller. It turns out this broke early in the v1.2 development cycle. We improved the device enumeration logic, but in the process missed this test case. It probably affects all versions of the Etron driver.

I've come up with a fix and verified it on my own USB3 port, which had until now never worked on V1.2 or V2.

Please try out and confirm: (removed box link, download V1.2.1, V2.0.2 or anything more recent). If this fully resolves the problem, we'll incorporate the fix into the next V2 skeletal release.

[Hoto]

Works perfect here under Windows 8.1 U1 x64. Now LM works again with USB3. Good Job, thx.

[pip25]

Yes, I can also confirm that this build fixes the problem on my 32 bit Win7 desktop as well. Thank you very much for looking into this, I can finally check out the v2 improvements.
EDIT: Ah, so this wasn't a v2 build... Oh well, I can wait.

[jdonald]

Thanks for confirming.

I just uploaded a V2 build to that same folder. (It's labeled winusb-fix-skeleton, although the WinUSB driver is default off for V2.)

[pip25]

Also works great, thank you! There are some definite improvements regarding the hand recognition as well, V2 looks to be well worth the wait!

[jdonald]

This is also fixed in the preview release of 1.2.1 as well as 2.0.2 for skeletal.