Change PIN does not work

[szszszsz]

Market issue (numerous reports, no details)
Occurence: frequent
OS: Windows
Version: 0.4 (from exe installer)
Nitrokey Pro

[szszszsz]

Not occurring on:

• Ubuntu 16.04, Nitrokey Pro v0.7, current master (c7b9b82)
• Windows 8.0, Nitrokey Storage v0.43, App version v0.4,

Confirmed on Windows 8.0, scenario:

1. Open Nitrokey App v0.4 (.exe downloaded from main site)
2. Insert Nitrokey Pro
3. Open Tray -> Configure -> OTP and Password Safe
4. Enter default admin PIN

Results:

• Message box will be shown that this is the default PIN
• Message box will be shown that this is incorrect PIN (incorrectly)
• While entering admin PIN 99 tries counter is shown (incorrectly)
• About window could show invalid serial number (longer than expected, 200 chars or more)

Observations:
After inserting device its red LED stays on for couple of seconds. It might be caused by checking its attributes by the OS. After the LED goes off device starts responding normally to Nitrokey App commands (it takes 3 minutes). Also if application is started after the device is inserted and the LED goes off then issue is not occurring (it takes much less time).

Current workaround:
Please run the application 30 seconds after the device insertion or when the device's LED goes off.

Possible cause:
Windows 8.0 itself is capable of using Smartcards for authorization (for login etc.). It probably blocks the device after insertion for a time making communication App <-> device difficult if at all possible.

[szszszsz]

It seems it is harder to reproduce the issue on application compiled from latest commit. It might be due to recent refactoring, changing getStatus poll delay to 2 seconds or both.
Compiled in latest QtCreator on Qt 5.7 with mingw-32 delivered with IDE.
Reinserting the device during the lockup might or might not help (under testing).

[szszszsz]

The issue has not been eliminated but its occurrence rate should be greatly lowered. Please reopen in case it would make Application and Stick unusable. Also another workaround (#156) will be prepared to avoid locking up device when it is not responsive.