Closed whoozle closed 9 years ago
might not be actual after #10
The behaviour is quite same - 1st launch is timeout, second - connect. And you could catch BUSY error if you'll be fast enough and try to connect just after USB is plugged in.
I would like to note one new detail which was observed before but wasn't reported. In case device is locked with PIN you'll get "TIMEOUT, ERROR, TIMEOUT..." loop. Where ERROR is "GetObjectHandles: invalid response code InvalidStorageID (0x2008)" and console output: "drop message 0003 201e, transaction 00000000, expected: 00000001".
EBUSY clearly indicates that someone else uses the same usb device.
I removed libusb and interact with usb devices directly for now, could you test the latest git revision ?
Same behaviour - one fail and then one successful attempt. Both in a loop. During failed one the app displays "timeout reaping usb urb"
Added 3 attempts of device restart in UI, could you test please?
I have connected the device.
1st launch: I got a busy message ioctl(_fd, USBDEVFS_CLAIMINTERFACE, &interfaceNumber): Устройство или ресурс занято
, which seems to be ok. Perhaps I was too fast.
2nd launch: I got timeout reaping usb urb
. GUI didn't open.
3rd launch: I got vector::_M_range_check:__n (which is 0) >= this->size() (which is 0)
. GUI opened but empty.
4th launch: GUI started and displayed correct content.
After step 4 any time you launch the app it works correctly till you unplug it. Which is great. Only need to eliminate steps 2-3. Console:
~/android-file-transfer-linux/build/qt$ ./android-file-transfer
upload worker started
invalid endpoint type Isoc
~/android-file-transfer-linux/build/qt$ ./android-file-transfer
upload worker started
invalid endpoint type Isoc
device info "NOKIA" "909"
exception timeout reaping usb urb: discard = 0
~/android-file-transfer-linux/build/qt$ ./android-file-transfer
upload worker started
invalid endpoint type Isoc
~/android-file-transfer-linux/build/qt$ ./android-file-transfer
upload worker started
invalid endpoint type Isoc
device info "NOKIA" "909"
drop message 0003 201e, transaction 00000000, expected: 00000001
~/android-file-transfer-linux/build/qt$ ./android-file-transfer
upload worker started
invalid endpoint type Isoc
device info "NOKIA" "909"
Perhaps tomorrow I'll try to debug it if I'll be able to build it with QtCreator.
Fixed «invalid endpoint type Isoc».
Added logs around opening session, could try again and send logs here please? :) The most strangest thing is that first message seems to be ok, I've added GetDeviceInfo message (NOKIA 909 comes from it), so I could check that mtp actually works.
Steps are same. New console output is:
$ ./qt/android-file-transfer
upload worker started
device info "NOKIA" "909"
device found, opening session...
3003 ms since the last poll call
exception timeout reaping usb urb: discard = 0
$ ./qt/android-file-transfer
upload worker started
$ ./qt/android-file-transfer
upload worker started
device info "NOKIA" "909"
device found, opening session...
drop message 0003 201e, transaction 00000000, expected: 00000001
session opened, starting
What happened the second time you started an app?
I got vector::_M_range_check:__n (which is 0) >= this->size() (which is 0)
message. GUI opened but empty.
Could you uncomment mtp/backend/linux/usb/Device.cpp:173 line (HexDump("read", ....) and leave it like this until we understand what's going on? :) Maybe your device use separate mtp headers or split bulk transaction somehow.
Done: http://pastebin.com/hc8Yw6rh
1st launch - timeout reaping usb urb
error.
2nd - vector::_M_range_check:__n (which is 0) >= this->size() (which is 0)
error
3rd - work as expected
Could you please repeat it once again with uncommented line Device.cpp:103, HexDump("write", ByteArray(data.data(), data.data() + r)); (HexDump("read" is needed too). I'm still puzzled about what's going on, everything looks ok for me, except duplicated session already opened message.
Weird. I've seen similar problems with libusb at the very beginning of mtp experimentation. If you're still interested in debugging, please check with wireshark the following scenario:
Please confirm that this scenario happened for you.
Also fixed important issue with string serialization. (missing zero byte from null termination character)
I think, i've managed to use wireshark under kubuntu.
There are 3 captures in this file
1 launch: I got timeout reaping usb urb
. GUI didn't open.
2 launch: I got vector::_M_range_check:__n (which is 0) >= this->size() (which is 0)
. GUI opened but empty.
3 launch: GUI started and displayed correct content.
first 4 packets in each capture seems to be some ping generated by wireshark itself.
Thank you. But this file could not be opened on my system, looks like it was not fully uploaded or something. This is second time I see your damaged files, maybe you have some system problems, like corrupted filesystem or unstable memory performance?
I'm able to download and open it with Ark. I've uploaded uncompressed files here: http://1drv.ms/1K4cr3E
Was you able to download uncompressed files?
Yes, I was, but they shows me exact the behavior I described above. Looks like your device actually sends reply to the command but kernel does not receive it (or does not set something on a bus, dunno). I need help from someone with deep knowledge of linux usb stack. :)
I have played with debugger and found that vector::_M_range_check:__n (which is 0) >= this->size() (which is 0)
error happens in GetDeviceInfoImpl()
at gdi.Read(stream);
bcs stream is empty. Read()
gets 03 00 01 20 00 00 00 00
which seems to be OK response with empty data.
And if you call _packeter.Read(0, data, code, response);
one more time in this case - the app work as expected.
But this problem happens only after problem No.1: timeout reaping usb urb
. So perhaps if we'll manage to solve it the second problem disappear at all.
And as for problem No.1 - I have a strong feeling that calling libusb_reset_device
and reopening a session will fix it. As you know, I experience a predictable sequence of problems: No.1, No.2 and everything fine after that. So I can expect which problem should happen this time.
Once just before probem No.1 I launched mtp-detect. It's output was:
Listing raw device(s)
Device 0 (VID=0421 and PID=0661) is a Nokia Nokia Lumia WP8.
Found 1 device(s):
Nokia: Nokia Lumia WP8 (0421:0661) @ bus 1, dev 10
Attempting to connect device(s)
PTP_ERROR_IO: failed to open session, trying again after resetting USB interface
LIBMTP libusb: Attempt to reset device
object 1 has parent 0xffffffff (-1) continuing anyway
object c has parent 0xffffffff (-1) continuing anyway
object 10 has parent 0xffffffff (-1) continuing anyway
object 403 has parent 0xffffffff (-1) continuing anyway
object 9ff has parent 0xffffffff (-1) continuing anyway
object a00 has parent 0xffffffff (-1) continuing anyway
USB low-level info:
bcdUSB: 512
...
And then I launched your app. Instead of problem No.1 (as expected) the app started to work normally. So calling libusb_reset_device
and reopening a session should solve WP problems. Could you make a branch with libusb
as backed that resets device and reopens session in case read timeout happens in Device::OpenSession
? I could test it.
linux documentation states that it might be dangerous:
Warning
Avoid using this request. It should probably be removed. Using it typically means the device and driver will lose toggle synchronization. If you really lost synchronization, you likely need to completely handshake with the device, using a request like CLEAR_HALT or SET_INTERFACE.
http://www.hep.by/gnu/kernel/usb/usbfs-ioctl.html
Could you send me the backtrace (bt) while catching this exception?
Also you could always switch on libusb backend in CMakeCache.txt (var USB_BACKEND_LIBUSB:BOOL=ON) or pass -D option to cmake.
At least I could fix packetizer to skip responses without data.
Could you send me the backtrace (bt) while catching this exception?
If you mean 2nd problem then backtrace seems to be:
8068bt
>&"bt\n"
>~"#0 0x00007ffff5da0267 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55\n"
>~"#1 0x00007ffff5da1eca in __GI_abort () at abort.c:89\n"
>~"#2 0x00007ffff63ac06d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6\n"
>~"#3 0x00007ffff63a9ee6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6\n"
>~"#4 0x00007ffff63a9f31 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6\n"
>~"#5 0x00007ffff63aa199 in __cxa_rethrow () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6\n"
>~"#6 0x0000000000493e49 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<mtp::Device, std::allocator<mtp::Device>, std::shared_ptr<mtp::usb::BulkPipe>&> (this=0x7fffffffd8a8, __a=...) at /usr/include/c++/4.9/bits/shared_ptr_base.h:626\n"
>~"#7 0x00000000004936a6 in std::__shared_ptr<mtp::Device, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<mtp::Device>, std::shared_ptr<mtp::usb::BulkPipe>&> (this=0x7fffffffd8a0, __tag=..., __a=...) at /usr/include/c++/4.9/bits/shared_ptr_base.h:1090\n"
>~"#8 0x0000000000492b5c in std::shared_ptr<mtp::Device>::shared_ptr<std::allocator<mtp::Device>, std::shared_ptr<mtp::usb::BulkPipe>&> (this=0x7fffffffd8a0, __tag=..., __a=...) at /usr/include/c++/4.9/bits/shared_ptr.h:316\n"
>~"#9 0x0000000000492159 in std::allocate_shared<mtp::Device, std::allocator<mtp::Device>, std::shared_ptr<mtp::usb::BulkPipe>&> (__a=...) at /usr/include/c++/4.9/bits/shared_ptr.h:588\n"
>~"#10 0x00000000004915d1 in std::make_shared<mtp::Device, std::shared_ptr<mtp::usb::BulkPipe>&> () at /usr/include/c++/4.9/bits/shared_ptr.h:604\n"
>~"#11 0x000000000048f9c8 in mtp::Device::Find () at ../mtp/ptp/Device.cpp:96\n"
>~"#12 0x000000000047866a in MainWindow::showEvent (this=0x7fffffffe300) at ../../qt/mainwindow.cpp:61\n"
>~"#13 0x00007ffff76eb141 in QWidget::event(QEvent*) () from /home/truf/Qt/5.4/gcc_64/lib/libQt5Widgets.so.5\n"
>~"#14 0x00007ffff780880b in QMainWindow::event(QEvent*) () from /home/truf/Qt/5.4/gcc_64/lib/libQt5Widgets.so.5\n"
>~"#15 0x00007ffff76af2b4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /home/truf/Qt/5.4/gcc_64/lib/libQt5Widgets.so.5\n"
>~"#16 0x00007ffff76b2c86 in QApplication::notify(QObject*, QEvent*) () from /home/truf/Qt/5.4/gcc_64/lib/libQt5Widgets.so.5\n"
>~"#17 0x00007ffff6930e24 in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /home/truf/Qt/5.4/gcc_64/lib/libQt5Core.so.5\n"
>~"#18 0x00007ffff76f0544 in QWidgetPrivate::show_helper() () from /home/truf/Qt/5.4/gcc_64/lib/libQt5Widgets.so.5\n"
>~"#19 0x00007ffff76f09b5 in QWidget::setVisible(bool) () from /home/truf/Qt/5.4/gcc_64/lib/libQt5Widgets.so.5\n"
>~"#20 0x0000000000477d3c in main (argc=1, argv=0x7fffffffe468) at ../../qt/main.cpp:52\n"
>8068^done
I've removed QApplication::notify() to disable exceptions suppression. Console:
terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)
linux documentation states that it might be dangerous:
I don't think they use USBDEVFS_RESETEP
Looks like libusb_reset_device
for linux is op_reset_device and they use USBDEVFS_RELEASEINTERFACE
and then IOCTL_USBFS_RESET
+ IOCTL_USBFS_DISCONNECT_CLAIM
. Perhaps these are safer?
I think there will be drawbacks, like re-initialization all usb device stack, timeouts, reinitialization of interfaces. I tried doing reset via libusb, it freezes usb devices until I plugged out usb cable, so I don't think it will work easily. Anyway, I removed any non-session requests except OpenSession, so no data request will be needed on startup. Please pull & test.
The problem # 2 seems to be workarounded:
$ ./qt/android-file-transfer
upload worker started
Object::connect: No such signal FileUploaderWorker::progress(qlonglong)
device found, opening session...
3003 ms since the last poll call
exception timeout reaping usb urb: discard = 0
timed out getting device info: timeout reaping usb urb , retrying...
reaping unknown urb, usb bus conflict: 0x7fffd9e369d0 0x7fffd9e368b0
terminate called without an active exception
Аварийный останов (сделан дамп памяти)
$ ./qt/android-file-transfer
upload worker started
Object::connect: No such signal FileUploaderWorker::progress(qlonglong)
device found, opening session...
drop message 0003 201e, transaction 00000000, expected: 00000001
drop message 0003 201e, transaction 00000000, expected: 00000001
device info "NOKIA" "909"
session opened, starting
I see, this might be race in kernel. Here's my thoughts on what happened:
I will try to store urbs in heap, to avoid stack corruption from kernel
Ok, please let me know when i could pull and retest.
I store urbs in map, so the could be reaped after discarding, please test. :)
Unfortunately, now I can't connect to device at all..
$ ./qt/android-file-transfer
upload worker started
device found, opening session...
3003 ms since the last poll call
error while submitting urb: timeout reaping usb urb
timed out getting device info: timeout reaping usb urb , retrying...
3003 ms since the last poll call
error while submitting urb: timeout reaping usb urb
timed out getting device info: timeout reaping usb urb , retrying...
3003 ms since the last poll call
error while submitting urb: timeout reaping usb urb
timed out getting device info: timeout reaping usb urb , retrying...
Ошибка сегментирования (сделан дамп памяти)
between last "retrying" and segfault i'm getting "MTP device does not respond" messagebox and able to see empty GUI. segfault happens when i'm closing GUI.
Output with hex dump http://pastebin.com/nwBrtDWd
well, we've got some sort of stability here. :)
Well, basically I changed almost nothing, except that old reaped urbs cannot be recognized as replies, so all expired urbs are really skipped. I think this is the difference. So, I see that first transaction was read. So, could you comment out line throw TimeoutException("timeout reaping usb urb");
, Device.cpp:152
and see if something changed for you. (this will call USBDEVFS_REAPURBNDELAY regardless of poll state).
That helped. Now first launch cause "Ресурс временно недоступен" massage and empty GUI. But second launch immediately after it works perfectly. Console:
$ ./qt/android-file-transfer
upload worker started
device found, opening session...
write:
00000000: 10 00 00 00 01 00 02 10 00 00 00 00 01 00 00 00
3003 ms since the last poll call
error while submitting urb: ioctl: Ресурс временно недоступен
Ошибка сегментирования (сделан дамп памяти)
$ ./qt/android-file-transfer
upload worker started
device found, opening session...
write:
00000000: 10 00 00 00 01 00 02 10 00 00 00 00 01 00 00 00
read:
00000000: 0c 00 00 00 03 00 01 20 00 00 00 00
write:
00000000: 0c 00 00 00 01 00 01 10 01 00 00 00
read:
00000000: 0c 00 00 00 03 00 1e 20 00 00 00 00
drop message 0003 201e, transaction 00000000, expected: 00000001
read:
00000000: ed 01 00 00 02 00 01 10 01 00 00 00 64 00 06 00
00000010: 00 00 64 00 51 6d 00 69 00 63 00 72 00 6f 00 73
00000020: 00 6f 00 66 00 74 00 2e 00 63 00 6f 00 6d 00 3a
00000030: 00 20 00 31 00 2e 00 30 00 3b 00 20 00 6d 00 69
00000040: 00 63 00 72 00 6f 00 73 00 6f 00 66 00 74 00 2e
00000050: 00 63 00 6f 00 6d 00 2f 00 44 00 65 00 76 00 69
00000060: 00 63 00 65 00 53 00 65 00 72 00 76 00 69 00 63
00000070: 00 65 00 73 00 3a 00 31 00 2e 00 30 00 3b 00 20
00000080: 00 6d 00 69 00 63 00 72 00 6f 00 73 00 6f 00 66
00000090: 00 74 00 2f 00 57 00 69 00 6e 00 64 00 6f 00 77
000000a0: 00 73 00 50 00 68 00 6f 00 6e 00 65 00 3a 00 31
000000b0: 00 2e 00 30 00 00 00 00 00 2f 00 00 00 01 10 02
000000c0: 10 03 10 04 10 05 10 06 10 07 10 08 10 09 10 0b
000000d0: 10 0c 10 12 10 0d 10 14 10 15 10 16 10 1a 10 1b
000000e0: 10 17 92 34 92 01 93 02 93 03 93 04 93 05 93 0a
000000f0: 93 01 94 02 94 03 94 04 94 05 94 10 94 11 94 12
00000100: 94 13 94 14 94 15 94 01 98 02 98 03 98 04 98 05
00000110: 98 06 98 08 98 10 98 11 98 20 98 06 00 00 00 04
00000120: 40 05 40 01 c3 03 c3 04 c3 01 c8 07 00 00 00 01
00000130: 50 02 d3 03 d3 01 d4 02 d4 05 d4 07 d4 00 00 00
00000140: 00 1a 00 00 00 00 30 01 30 04 30 09 30 0a 30 01
00000150: 38 01 b9 03 b9 81 b9 03 ba 05 ba 0b ba 07 38 08
00000160: 38 0b 38 0d 38 04 38 04 b8 82 b9 15 b2 16 b2 84
00000170: b9 85 b9 83 ba 85 ba 86 ba 06 4e 00 4f 00 4b 00
00000180: 49 00 41 00 00 00 04 39 00 30 00 39 00 00 00 0d
00000190: 38 00 2e 00 31 00 30 00 2e 00 31 00 34 00 32 00
000001a0: 32 00 36 00 2e 00 30 00 00 00 21 36 00 35 00 62
000001b0: 00 36 00 65 00 61 00 33 00 65 00 33 00 38 00 30
000001c0: 00 64 00 37 00 64 00 64 00 62 00 33 00 36 00 31
000001d0: 00 39 00 65 00 32 00 63 00 62 00 39 00 36 00 34
000001e0: 00 30 00 39 00 31 00 34 00 66 00 00 00
read:
00000000: 0c 00 00 00 03 00 01 20 01 00 00 00
device info "NOKIA" "909"
write:
00000000: 18 00 00 00 01 00 07 10 02 00 00 00 ff ff ff ff
00000010: 00 00 00 00 ff ff ff ff
read:
00000000: 28 00 00 00 02 00 07 10 02 00 00 00 06 00 00 00
00000010: 01 00 00 00 0c 00 00 00 10 00 00 00 03 04 00 00
00000020: ff 09 00 00 00 0a 00 00
read:
00000000: 0c 00 00 00 03 00 01 20 02 00 00 00
session opened, starting
write:
00000000: 10 00 00 00 01 00 08 10 03 00 00 00 10 00 00 00
read:
00000000: b2 00 00 00 02 00 08 10 03 00 00 00 01 00 01 00
00000010: 01 30 01 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030: 00 00 ff ff ff ff 01 00 01 00 00 00 00 00 00 00
00000040: 06 4d 00 75 00 73 00 69 00 63 00 00 00 17 32 00
00000050: 30 00 31 00 33 00 30 00 33 00 31 00 30 00 54 00
00000060: 31 00 36 00 34 00 35 00 35 00 37 00 2e 00 31 00
00000070: 2b 00 30 00 34 00 30 00 30 00 00 00 17 32 00 30
00000080: 00 31 00 35 00 30 00 34 00 32 00 31 00 54 00 31
00000090: 00 38 00 31 00 35 00 31 00 32 00 2e 00 39 00 2b
000000a0: 00 30 00 34 00 30 00 30 00 00 00 00 00 00 00 00
000000b0: 00 00
read:
00000000: 0c 00 00 00 03 00 01 20 03 00 00 00
write:
00000000: 10 00 00 00 01 00 08 10 04 00 00 00 0c 00 00 00
read:
00000000: ba 00 00 00 02 00 08 10 04 00 00 00 01 00 01 00
00000010: 01 30 01 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030: 00 00 ff ff ff ff 01 00 01 00 00 00 00 00 00 00
00000040: 0a 44 00 6f 00 77 00 6e 00 6c 00 6f 00 61 00 64
00000050: 00 73 00 00 00 17 32 00 30 00 31 00 34 00 30 00
00000060: 38 00 31 00 36 00 54 00 30 00 31 00 35 00 37 00
00000070: 30 00 37 00 2e 00 30 00 2b 00 30 00 34 00 30 00
00000080: 30 00 00 00 17 32 00 30 00 31 00 35 00 30 00 34
00000090: 00 32 00 34 00 54 00 31 00 32 00 35 00 36 00 33
000000a0: 00 35 00 2e 00 32 00 2b 00 30 00 34 00 30 00 30
000000b0: 00 00 00 00 00 00 00 00 00 00
read:
00000000: 0c 00 00 00 03 00 01 20 04 00 00 00
write:
00000000: 10 00 00 00 01 00 08 10 05 00 00 00 01 00 00 00
read:
00000000: ba 00 00 00 02 00 08 10 05 00 00 00 01 00 01 00
00000010: 01 30 01 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030: 00 00 ff ff ff ff 01 00 01 00 00 00 00 00 00 00
00000040: 0a 44 00 6f 00 63 00 75 00 6d 00 65 00 6e 00 74
00000050: 00 73 00 00 00 17 32 00 30 00 31 00 33 00 30 00
00000060: 33 00 31 00 30 00 54 00 31 00 36 00 34 00 35 00
00000070: 35 00 39 00 2e 00 39 00 2b 00 30 00 34 00 30 00
00000080: 30 00 00 00 17 32 00 30 00 31 00 35 00 30 00 34
00000090: 00 30 00 38 00 54 00 31 00 33 00 31 00 36 00 35
000000a0: 00 33 00 2e 00 32 00 2b 00 30 00 34 00 30 00 30
000000b0: 00 00 00 00 00 00 00 00 00 00
read:
00000000: 0c 00 00 00 03 00 01 20 05 00 00 00
write:
00000000: 10 00 00 00 01 00 08 10 06 00 00 00 00 0a 00 00
read:
00000000: b4 00 00 00 02 00 08 10 06 00 00 00 01 00 01 00
00000010: 01 30 01 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030: 00 00 ff ff ff ff 01 00 01 00 00 00 00 00 00 00
00000040: 07 56 00 69 00 64 00 65 00 6f 00 73 00 00 00 17
00000050: 32 00 30 00 31 00 33 00 30 00 33 00 31 00 30 00
00000060: 54 00 31 00 36 00 34 00 35 00 35 00 37 00 2e 00
00000070: 37 00 2b 00 30 00 34 00 30 00 30 00 00 00 17 32
00000080: 00 30 00 31 00 35 00 30 00 31 00 31 00 33 00 54
00000090: 00 31 00 36 00 32 00 37 00 31 00 39 00 2e 00 34
000000a0: 00 2b 00 30 00 34 00 30 00 30 00 00 00 00 00 00
000000b0: 00 00 00 00
read:
00000000: 0c 00 00 00 03 00 01 20 06 00 00 00
write:
00000000: 10 00 00 00 01 00 08 10 07 00 00 00 ff 09 00 00
read:
00000000: ba 00 00 00 02 00 08 10 07 00 00 00 01 00 01 00
00000010: 01 30 01 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030: 00 00 ff ff ff ff 01 00 01 00 00 00 00 00 00 00
00000040: 0a 52 00 69 00 6e 00 67 00 74 00 6f 00 6e 00 65
00000050: 00 73 00 00 00 17 32 00 30 00 31 00 33 00 30 00
00000060: 33 00 31 00 30 00 54 00 31 00 36 00 34 00 36 00
00000070: 30 00 30 00 2e 00 32 00 2b 00 30 00 34 00 30 00
00000080: 30 00 00 00 17 32 00 30 00 31 00 33 00 30 00 33
00000090: 00 31 00 30 00 54 00 31 00 36 00 34 00 36 00 30
000000a0: 00 30 00 2e 00 32 00 2b 00 30 00 34 00 30 00 30
000000b0: 00 00 00 00 00 00 00 00 00 00
read:
00000000: 0c 00 00 00 03 00 01 20 07 00 00 00
write:
00000000: 10 00 00 00 01 00 08 10 08 00 00 00 03 04 00 00
read:
00000000: b8 00 00 00 02 00 08 10 08 00 00 00 01 00 01 00
00000010: 01 30 01 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030: 00 00 ff ff ff ff 01 00 01 00 00 00 00 00 00 00
00000040: 09 50 00 69 00 63 00 74 00 75 00 72 00 65 00 73
00000050: 00 00 00 17 32 00 30 00 31 00 33 00 30 00 33 00
00000060: 31 00 30 00 54 00 31 00 36 00 34 00 35 00 35 00
00000070: 38 00 2e 00 31 00 2b 00 30 00 34 00 30 00 30 00
00000080: 00 00 17 32 00 30 00 31 00 33 00 31 00 30 00 32
00000090: 00 31 00 54 00 31 00 35 00 30 00 30 00 35 00 30
000000a0: 00 2e 00 33 00 2b 00 30 00 34 00 30 00 30 00 00
000000b0: 00 00 00 00 00 00 00 00
read:
00000000: 0c 00 00 00 03 00 01 20 08 00 00 00
I suspect that Kubuntu works with device just after it's plugged in. And perhaps it doesn't release it properly after that. I waited a few minutes after device was plugged - but still got this busy error message.
Launching mtp-detect
to reset usb at very beginning changes nothing.
Just the first. I'm launching the app, getting error, then empty GUI appears. And only when I close empty GUI I'm getting segfault message.
So, just for clarity, with that line commented, you could launch application as many times as you want without problems, except the first?
Device.cpp:152
possibly fixed segmentation fault at exit, empty ui should not show anymore.
Hm, now i don't see empty GUI. App quits without segfault just after Device is not responding error message displayed. The problem is that now I can't connect to device. Console:
$ ./qt/android-file-transfer
upload worker started
device found, opening session...
write:
00000000: 10 00 00 00 01 00 02 10 00 00 00 00 01 00 00 00
3003 ms since the last poll call
error while submitting urb: timeout reaping usb urb
timed out getting device info: timeout reaping usb urb , retrying...
write:
00000000: 10 00 00 00 01 00 02 10 00 00 00 00 01 00 00 00
3003 ms since the last poll call
error while submitting urb: timeout reaping usb urb
timed out getting device info: timeout reaping usb urb , retrying...
write:
00000000: 10 00 00 00 01 00 02 10 00 00 00 00 01 00 00 00
3003 ms since the last poll call
error while submitting urb: timeout reaping usb urb
timed out getting device info: timeout reaping usb urb , retrying...
Only twice I was able to connect when launched the app just after device was plugged in. And it was connected on 2nd of 3 attempts so it seems to be just a luck.
can you test it on the latest master? I included proper ZLP handling, it might help your device. :)
Ok
2015-06-02 14:36 GMT+04:00 Vladimir notifications@github.com:
can you test it on the latest master? I included proper ZLP handling, it might help your device. :)
— Reply to this email directly or view it on GitHub https://github.com/whoozle/android-file-transfer-linux/issues/12#issuecomment-107912111 .
With best regards, Alexander Trufanov
Amazing, it works now.
$ ./qt/android-file-transfer
kf5.kiconthemes: "Theme tree: (Breeze)"
upload worker started
device found, opening session...
device info "NOKIA" "909"
switching to storage id 65537
session opened, starting
It might spend a few seconds on "device found, opening session..." during first launch but this is fine.
The only thing I would suggest is to give informative error message in case device can't be connected, bcs it's locked. In this case app's output is:
$ ./qt/android-file-transfer
kf5.kiconthemes: "Theme tree: (Breeze)"
upload worker started
device found, opening session...
device info "NOKIA" "909"
And message box with Get: invalid response code InvalidStorageID (0x2008)
is displayed.
Btw, if device screen is on at this moment it even pull out its virtual keypad suggesting user that he should unlock the device. But if device screen wasn't on then it's not clear what happened. It also could confuse bcs device could automatically lock itself after N minutes of idle mode when screen is switched off. So it would be great to provide more informative warning.
But it's a minor issue. Feel free to close this issue.
I'm happy with current implementation and will recommend this project as only app able to connect to WP phones (at least my Lumia 1020 WP 8.1 Denim) via wire under Ubuntu systems.
Configuring devices often leads to timeouts. Intercepted traffic shows that proper device response was delayed until exiting from app. libusb bug?