kbhomes / libmtp-zune Goto Github PK

View Code? Open in Web Editor NEW

34.0 8.0 19.0 5.58 MB

Adding Zune support to libmtp.

License: GNU Lesser General Public License v2.1

C 99.50% Shell 0.50%

libmtp-zune's Introduction

Building and Installing
-----------------------

See the "INSTALL" file.

Initiator and Responder
-----------------------

libmtp implements an MTP initiator, which means it initiate
MTP sessions with devices. The devices responding are known
as MTP responders. libmtp runs on something with a USB host
controller interface, using libusb to access the host
controller.

If you're more interested in the MTP responders, gadgets like
MP3 players, mobile phones etc, look into MeeGo:s Buteo Sync:
http://wiki.meego.com/Buteo - these guys are creating a fully
open source MTP responder.

Heritage
--------

libmtp is based on several ancestors:

* libptp2 by Mariusz Woloszyn was the starting point used
by Richard A. Low for the initial starter port. You can
find it at http://libptp.sourceforge.net/

* libgphoto2 by Mariusz Woloszyn and Marcus Meissner was
used at a later stage since it was (is) more actively
maintained. libmtp tracks the PTP implementation in
libgphoto2 and considers it an upstream project. We will
try to submit anything generally useful back to libgphoto2
and not make double efforts. In practice this means we
use ptp.c, ptp.h and ptp-pack.c verbatim from the libgphoto2
source code. If you need to change things in these files,
make sure it is so general that libgphoto2 will want to
merge it to their codebase too. You find libgphoto2 as part
of gPhoto: http://gphoto.sourceforge.net/

* libnjb was a project that Richard and Linus were working
on before libmtp. When Linus took Richards initial port
and made an generic C API he re-used the philosophy and
much code from libnjb. Many of the sample programs are for
example taken quite literally from libnjb. You find it here:
http://libnjb.sourceforge.net/

Contacting and Contributing
---------------------------

See the project page at http://libmtp.sourceforge.net/
We always need your help. There is a mailinglist and a
bug report system there.

People who want to discuss MTP devices in fora seem to
hang out on the forums at AnythingbutiPod:
http://www.anythingbutipod.com/forum/

Compiling programs for libmtp
-----------------------------

libmtp has support for the pkg-config script by adding a libmtp.pc
entry in $(prefix)/lib/pkgconfig. To compile a libmtp program,
"just" write:

gcc -o foo `pkg-config --cflags --libs libmtp` foo.c

This also simplifies compilation using autoconf and pkg-config: just
write e.g.

PKG_CHECK_MODULES(MTP, libmtp)
AC_SUBST(MTP_CFLAGS)
AC_SUBST(MTP_LIBS)

To have libmtp LIBS and CFLAGS defined. Needless to say, this will
only work if you have pkgconfig installed on your system, but most
people have nowadays.

If your library is installed in e.g. /usr/local you may have to tell
this to pkgconfig by setting the PKG_CONFIG_PATH thus:

export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig

Documentation
-------------

Read the API documentation that can be generated with doxygen.
It will be output in doc/html if you have Doxygen properly
installed. (It will not be created unless you have Doxygen!)

For information about the Media Transfer Protocol, see:
http://en.wikipedia.org/wiki/Media_Transfer_Protocol

The official 1.0 specification for MTP was released by the
USB Implementers Forum in may, 2008. Prior to this, only a
proprietary Microsoft version was available, and quite a few
devices out there still use some aspects of the Microsoft
version, which deviates from the specified standard. You can
find the official specification here:
http://www.usb.org/developers/devclass_docs/MTP_1.0.zip

The Examples
------------

In the subdirectory "examples" you find a number of
command-line tools, illustrating the use of libmtp in very
simple terms.

Please do not complain about the usability or documentation
of these examples, they look like they do for two reasons:

1. They are examples, not tools. If they were intended for
day-to-day usage by commandline freaks, I would have
called them "tools" not "examples".

2. The MTP usage paradigm is that a daemon should hook
the device upon connection, and that it should be
released by unplugging. GUI tools utilizing HAL (hald)
and D-Bus do this much better than any commandline
program ever can. (See below on bugs.) Specificationwise
this is a bug, however it is present in many, many
devices.

That said, if you want to pick up and maintain the examples,
please volunteer.

FAQ: Common Problems
--------------------

Some MTP devices have strange pecularities. We try to work around
these whenever we can, sometimes we cannot work around it or we
cannot test your solution.

* mtp-* tools doesn't work because someone else is already hogging
the device

This is a common problem, the most common case could be that
gphoto2 (which can also talk PTP/MTP) is taking over the device
as soon as it's plugged in. Some distributions are configured that
way. Counter it like this:

gvfs-mount -s gphoto2

Then re-attach the device.

Sometimes the "gvfs-gphoto2-volume-monitor" is running on the
system and hogging the device, try something like:

pkill gfvs-gphoto2-volume-monitor

Then plug in the device and issue "mtp-detect" to figure out if
this may be the case.

* Generic MTP/PTP disconnect misbehaviour: we have noticed that
Windows Media Player apparently never close the session to an MTP
device. There is a daemon in Windows that "hooks" the device
by opening a PTP session to any MTP device, whenever it is
plugged in. This daemon proxies any subsequent transactions
to/from the device and will never close the session, thus
Windows simply does not close sessions at all.

For example this means that a device may work the first time
you run some command-line example like "mtp-detect" while
subsequent runs fail.

Typical sign of this illness: broken pipes on closing sessions,
on the main transfer pipes(s) or the interrupt pipe:

Closing session
usb_clear_halt() on INTERRUPT endpoint: Broken pipe
OK.

This means that device manufacturers doesn't notice any problems
with devices that do not correctly handle closing PTP/MTP
sessions, since Windows never do it. The proper way of closing
a session in Windows is to unplug the device, simply put.

Since libmtp actually tries to close sessions, some devices
may fail since the close session functionality has never been
properly tested, and "it works with Windows" is sort of the
testing criteria at some companies.

You can get Windows-like behaviour on Linux by running a udev-aware
libmtp GUI client like Rhythmbox or Gnomad2, which will "hook"
the device when you plug it in, and "release" it if you unplug
it, and you start/end you transfer sessions by plugging/unplugging
the USB cable.

The "Unix way" of running small programs that open the device,
do something, then close the device, isn't really working with
such devices and you cannot expect to have command line tools
like the mtp examples work with them. You could implement new
example programs that just call to a mediating daemon like the
Windows MTP stack does. (And change all programs using libmtp
directly today.)

If this bug in your device annoys you, contact your device
manufacturer and ask them to test their product with some libmtp
program.

* Android locked screen: some devices just report zero files
and no storages when the device is locked, probably so as not
to allow the MTP access to be used as a "backdoor" into the
device. Unlock the device before listing files, set the autolock
to some large value or disabled if it disturbs you, you are
causing this to yourself.

* Samsung Android 2.3.x devices: these have a special MTP stack
with some specific bugs that we have maybe nailed down now.
It suffers from an "immediate connect" syndrome, i.e. you have
to connect to the device within 7 seconds of plugging in, or it
will go numb. This also goes for command-line activity with
the example programs, so this device is better used with a
GUI tool like Rhythmbox, gnomad2...

* Generic USB misbehaviour: some devices behave badly under MTP
and USB mass storage alike, even down to the lowest layers
of USB. You can always discuss such issues at the linux-usb
mailing list if you're using Linux:
http://www.linux-usb.org/mailing.html

If you have a problem specific to USB mass storage mode, there
is a list of strange behaving devices in the Linux kernel:
http://lxr.linux.no/linux/drivers/usb/storage/unusual_devs.h
You can discuss this too on the mentioned list, for understanding
the quirks, see:
http://www2.one-eyed-alien.net/~mdharm/linux-usb/target_offenses.txt

* Generic certificate misbehaviour. All devices are actually
required to support a device certificate to be able to
encrypt Windows Media (WMA/WMV) files. However there are
obviously a lot of devices out there which doesn't support
this at all but instead crash. Typical printout:

Error 2: PTP Layer error 02ff: get_device_unicode_property(): failed
to get unicode property.

This should only affect "mtp-detect", there is no other
application currently retrieveing the certificate (not that we
know anyway).

* Kernel bug on Linux. Linux 2.6.16 is generally speaking required
to use any MTP device under USB 2.0. This is because the EHCI
driver previously did not support zero-length writes to endpoints.
It should work in most cases however, or if you connect it
to an UHCI/OHCI port instead (yielding lower speed). But
please just use a recent kernel.

* Zen models AVI file seeking problem: the Zens cannot parse the
files for the runlength metadata. Do not transfer file with e.g.
mtp-sendfile, use mtp-sendtr and set the length of the track to
the apropriate number of seconds and it will work. In graphical
clients, use a "track transfer" function to send these AVI files,
the Zens need the metadata associated with tracks to play back
movies properly. Movies are considered "tracks" in the MTP world.

* Some devices that disregard the metadata sent with the MTP
commands will parse the files for e.g. ID3 metadata. Some still
of these devices expect only ID3v2.3 metadata and will fail with
a modern ID3v2,4 tag writer, like many of those found in Linux
applications. Windows Media Player use ID3v2.3 only, so many
manufacturers only test this version.

* The Zen Vision:M (possibly more Creative Zens) has a firmware bug
that makes it drop the last two characters off a playlist name.
It is fixed in later firmware.

* For Creative Technology devices, there are hard limits on how
many files can be put onto the device. For a 30 GiB device (like
the Zen Xtra) the limit is 6000, for a 60 GiB device the limit
is 15000 files. For further Creative pecularities, see the
FAQ sections at www.nomadness.net.

* Sandisk sansa c150 and probably several other Sandisk devices
(and possibly devices from other manufacturers) have a dual
mode with MTP and USB mass storage. The device will initially
claim to be mass storage so udev will capture is and make the
use of MTP mode impossible. One way of avoiding it could be to
be to blacklist the "usb-storage" module in
/etc/modprobe.c/blacklist with a row like this:
"blacklist usb-storage". Some have even removed the
"usb-storage.ko" (kernel module file) to avoid loading.

* Sandisk Sansa Fuze has three modes: auto, MTP or mass storage
(MSC). Please set it to MTP to avoid problems with libmtp.

* The iriver devices (possibly all of them) cannot handle the
enhanced GetObjectPropList MTP command (0x9805) properly. So
they have been banned from using it.

* iriver devices have problems with older versions of libmtp and
with new devices libmtp does not know of as of yet, since it
has an oldstyle USB device controller that cannot handle zero
writes. (Register your device with us!) All their devices are
likely to need a special device flag in the src/libusb-glue.c
database.

* The Samsung Yepp T9 has several strange characteristics, some
that we've managed to work around. (For example it will return
multiple PTP packages in a single transaction.)

* The early firmware for Philips HDD players is known to be
problematic. Please upgrade to as new firmware as you can get.
(Yes this requires some kind of Windows Installation I think.)

* Philips HDD 1630/16 or 1630/17 etc may lock themselves up,
turning inresponsive due to internal corruption. This typically
gives an error in opening the PTP session. Apparently you can
do a "repair" with the firmware utility (Windows only) which
will often fix this problem and make the device responsive
again.

* Some devices that implement GetObjectPropList (0x9805) will
not return the entire object list if you request a list for object
0xffffffffu. (But they should.) So they may need the special
DEVICE_FLAG_BROKEN_MTPGETOBJPROPLIST_ALL.

* Some (smaller) subset of devices cannot even get all the
properties for a single object in one go, these need the
DEVICE_FLAG_BROKEN_MTPGETOBJPROPLIST. Currently only the
iriver devices seem to have this bug.

* The Toshiba Gigabeat S (and probably its sibling the
Microsoft Zune and other Toshiba devices) will only display
album information tags for a song in case there is also
an abstract album (created with the album interface) with
the exact same name.

* The Zen Vision:M has an older firmware which is very corrupt,
it is incompatible with the Linux USB stack altogether. The
kernel dmesg will look something like this, and you have to
upgrade the firmware using Windows:
usb 4-5: new high speed USB device using ehci_hcd and address 5
usb 4-5: configuration #1 chosen from 1 choice
usb 4-5: can't set config #1, error -110

* The Sirus Stiletto does not seem to allow you to copy any files
off the device. This may be someone's idea of copy protection.

* The Samsung P2 assigns parent folder ID 0 to all unknown file
types.(i.e. moves them to the root folder)

* The Sandisk Sansa Clip+ needs a firmware upgrade in earlier
versions in order to work properly.

New Devices
-----------

If you happen upon a device which libmtp claims it cannot
autodetect, please submit the vendor ID and device ID
(these can be obtained from the "lsusb" and "lsusb -n"
commands run as root) as a bug, patch or feature request
on the Sourceforge bug tracker at our homepage. If it
gives a sensible output from "mtp-detect" then please attach
the result as well as it teach us some stuff about your
device. If you've done some additional hacking, join our
mailinglist and post your experiences there.

If you want to be able to hack some more and you're not
afraid of C hacking, add an entry for your device's
vendor/product ID and a descriptive string to the database
in the file src/music-players.h.

If you want to poke around to see if your device has some
special pecularities, you can test some special device
flags (defined in src/device-flags.h) by inserting them
together with your device entry in src/music-players.h.
Flags can be tested in isolation or catenated with "|"
(binary OR). If relatives to your device use a certain
flag, chances are high that a new device will need it
too, typically from the same manufacturer.

The most common flag that needs to be set is the
DEVICE_FLAG_UNLOAD_DRIVER that detach any Linux kernel
drivers that may have attached to the device making
MTP access impossible. This is however not expected to
really work: this is a problem being tracked as of
now (2007-08-04). See the "last resort" solutions below
if you really need to get your dual-mode device to work
with MTP.

Another flag which is easy to identify is the
DEVICE_FLAG_NO_ZERO_READS, which remedies connection
timeouts when getting files, and some timeouts on e.g.
successive "mtp-connect" calls.

If your device is very problematic we are curious of how it
works under Windows, so we enjoy reading USB packet sniffs
that reveal the low-level traffic carried out between
Windows Media Player and your device. This can be done
using e.g.:

* USBsnoop:
http://benoit.papillault.free.fr/usbsnoop/

* The trial version of HHD Softwares software-only
USB monitor. You need to get a copy of version 2.37 since
the newer trial versions won't let you carry out the
needed packet sniffs. (As of 2007-03-10 a copy can be found
at: http://www.cobbleware.com/files/usb-monitor-237.exe)

There are other USB monitors as well, some more expensive
alternatives use hardware and even measure electronic
characteristics of the traffic (which is far too much
detail for us).

Device sniffs are an easy read since the PTP/MTP protocol
is nicely structured. All commands will have a structure such
as this in the log, we examplify with a object list request:

PTP REQEUST:
000120: Bulk or Interrupt Transfer (UP), 03.09.2007 12:49:25.9843750 +0.0
Pipe Handle: 0x863ce234 (Endpoint Address: 0x2)
Send 0x20 bytes to the device:
20 00 00 00 01 00 05 98 23 00 00 00 27 03 00 10 ......?#...'...
Length TYPE CMD Trans# Param1

00 00 00 00 02 DC 00 00 00 00 00 00 00 00 00 00 .....Ü..........
Param2 Param3 Param4 Param5

[OPTIONAL] DATA PHASE:
000121: Bulk or Interrupt Transfer (UP), 03.09.2007 12:49:26.0 +0.0156250
Pipe Handle: 0x863ce214 (Endpoint Address: 0x81)
Get 0x1a bytes from the device:
1A 00 00 00 02 00 05 98 23 00 00 00 01 00 00 00 .......?#.......
Length TYPE CMD Trans# DATA

27 03 00 10 02 DC 04 00 00 30 '....Ü...0

RESPONSE:
000122: Bulk or Interrupt Transfer (UP), 03.09.2007 12:49:26.0 +0.0
Pipe Handle: 0x863ce214 (Endpoint Address: 0x81)
Get 0xc bytes from the device:
0C 00 00 00 03 00 01 20 23 00 00 00 ....... #...
Length TYPE CODE Trans#

* One send (OUT to the device), two reads (IN from the device).

* All three byte chunks commands are
sent/recieved/recieeved by the function ptp_transaction()
in the file ptp.c.

* It boils down to ptp_usb_sendreq(), optionally ptp_usb_senddata()
or ptp_usb_getdata() and finally ptp_usb_getresp() in the file
libusb-glue.c. Notice ptp_usb_sendreq() and ptp_usb_getresp()
are ALWAYS called. The TYPE field correspond to this, so the
TYPES in this case are "COMMAND" (0x0001), "DATA" (0x0002),
and "RESPONSE" (0x0003).

* Notice that the byte order is little endian, so you need to read
each field from right to left.

* This COMMAND has:
CMD 0x99805, we see in ptp.h that this is PTP_OC_MTP_GetObjPropList.
Transaction# 0x00000023.
REQUEST parameters 0x10000327, 0x00000000, 0x0000DC02, 0x00000000
0x00000000, in this case it means "get props for object 0x10000327",
"any format", "property 0xDC02" (PTP_OPC_ObjectFormat), then two
parameters that are always zero (no idea what they mean or their
use).

* The DATA has:
CMD 0x99805, we see in ptp.h that this is PTP_OC_MTP_GetObjPropList.
Transaction# 0x00000023.
Then comes data 0x00000001, 0x10000327, 0xDC02, 0x0004, 0x3000
Which means in this case, (and this is the tricky part) "here
you have 1 property", "for object 0x10000327", "it is property
0xDC02" (PTP_OPC_ObjectFormat), "which is of type 0x0004"
(PTP_DTC_UINT16), "and set to 0x3000" (PTP_OFC_Undefined, it
is perfectly valid to have undefined object formats, since it
is a legal value defining this).

* This RESPONSE has:
CMD 0x99805, we see in ptp.h that this is PTP_OC_MTP_GetObjPropList.
Return Code ("RC") = 0x2001, PTP_RC_OK, all went fine.
Transaction# 0x00000023.

If you want to compare the Windows behaviour with a similar
operation using libmtp you can go into the src/libusb-glue.c
file and uncomment the row that reads:

//#define ENABLE_USB_BULK_DEBUG

(I.e. remove the two //.)

This will make libmtp print out a hex dump of every bulk USB
transaction. The bulk transactions contain all the PTP/MTP layer
data, which is usually where the problems appear.

Notes to assist with debugging new devices:
-------------------------------------------

In debugging new hardware, we highly recommend that you only
use the example mtp-* applications that come with libmtp, as other
applications may have their own bugs that may interfere with your
new device working correctly. Using another application instead of
those that come with libmtp just adds another point of failure.

For debugging, there are 3 main options:

1. Use the env variable: LIBMTP_DEBUG to increase the
verboseness of the debugging output for any application using
libmtp. Relevant codes are:
* 0x00 [0000 0000] : no debug (default)
* 0x01 [0000 0001] : PTP debug
* 0x02 [0000 0010] : Playlist debug
* 0x04 [0000 0100] : USB debug
* 0x08 [0000 1000] : USB data debug
// Codes are hex and binary respectively. Simple add them togther
// to get your desired level of output.

(Assuming bash)
eg:
$ export LIBMTP_DEBUG=12
$ mtp-detect
// To get USB debug and USB data debug information.

$ export LIBMTP_DEBUG=2
$ mtp-detect
// To get Playlist debug information.

Also note, an application may also use the LIBMTP_debug() API
function to achieve the same options as listed above.

2. Use "strace" on the various mtp-* commands to see where/what
is falling over or getting stuck at.
* On Solaris and FreeBSD, use "truss" or "dtrace" instead on "strace".
* On Mac OS X, use "ktrace" or "dtrace" instead of "strace".
* On OpenBSD and NetBSD, use "ktrace" instead of "strace".

This will at least help pinpoint where the application is failing, or
a device is reporting incorrect information. (This is extremely helpful
with devices that have odd disconnection requirements).

The use of these tools may also pinpoint issues with libusb as
implemented by each OS vendor or issues with the MTP implementation
on the new device as well, so please be prepared for either case.

3. Use "gdb" or similar debugger to step through the code as it is
run. This is time consuming, and not needed just to pinpoint where
the fault is.

The use of gdb or another debugger may also miss or actually cause
command and data timing issues with some devices, leading to false
information. So please consider this a last resort option.

Also please read the "It's Not Our Bug!" section below, as it does
contain some useful information that may assist with your device.

Dual-mode devices does not work - last resort:
----------------------------------------------

Some devices that are dual-mode are simply impossible to get
to work under Linux because the usb-storage(.ko) kernel
module hook them first, and refuse to release them, even
when we specify the DEVICE_FLAG_UNLOAD_DRIVER flag. (Maybe
it DOES release it but the device will immediately be probed
at the USB mass storage interface AGAIN because it
enumerates.)

Here is what some people do:

1. Plug in the device.
2. USB-mass storage folder will open automatically.
3. Unmount the device.
4. Run mtp-detect. It will most likely fail the first time.
5. Run mtp-detect again, it might work this time, or fail. Keep running
till it works. 99% it works by the third try.
6. Once mtp-detect gives you an "Ok", open either Rhythmbox or Gnomad2,
everything should work.

Linux: Try this, if you have a recent 2.6.x Linux kernel,
run (as root) something like:

> rmmod usb_storage ; mtp-detect

You can run most any command or a client like gnomad2 or
Amarok immediately after the rmmod command. This works
sometimes. Another way:

* Edit /etc/modprobe.d/blacklist

* Add the line "blacklist usb-storage"

* Reboot.

Now none of you USB disks, flash memory sticks etc will be
working (you just disabled them all). However you *can* try
your device, and it might have started working because there
is no longer a USB mass storage driver that tries to hook onto
the mass storage interface of your device.

If not even blacklisting works (check with
"lsmod | grep usb-storage"), there is some problem with
something else and you may need to remove or rename the file
/lib/modules/<VERSION>/kernel/drivers/usb/storage/usb-storage.ko
manually.

If you find the PerfectSolution(TM) to this dilemma, so you
can properly switch for individual devices whether to use it
as USB mass storage or not, please tell us how you did it. We
know we cannot use udev, because udev is called after-the-fact:
the device is already configured for USB mass storage when
udev is called.

On Mac OS there is another ugly hack:

1. Open up a terminal window
2. Type:
sudo mv /System/Library/Extensions/IOUSBMassStorageClass.kext
/System/Library/Extensions/IOUSBMassStorageClass.kext.disabled

and when prompted enter your password.

3. Restart.

To reverse this change, just reverse the filenames:

sudo mv /System/Library/Extensions/
IOUSBMassStorageClass.kext.disabled /System/Library/Extensions/
IOUSBMassStorageClass.kext

and restart.

Calendar and contact support:
-----------------------------

The Creative Zen series can read VCALENDAR2 (.ics) files
and VCard (.vcf) files from programs like for example
Evolution with the following limitations/conditions:

- The file must be in DOS (CR/LF) format, use the unix2dos
program to convert if needed

- Repeat events in calendar files do not seem to be supported,
entries will only appear once.

- Calendar (.ics) files should be stored in the folder "My Organizer"
when sent to the device (this directory should be autodetected
for use with calendar files, otherwise use the option
-f "My Organizer" to sendfile for this) Apparently this file can
also contain tasklists.

- Contact (.vcf) files should be stored in the folder "My Contacts"
when sent to the device. (-f "My Contacts")

- Some devices are picky about the name of the calendar and
contact files. For example the Zen Microphoto wants:

Calendar: My Organizer/6651416.ics
Contacts: My Organizer/6651416.vcf

Syncing in with Evolution and Creative Devices
----------------------------------------------

Evolution can easily export .ics an .vcf files, but you currently
need some command-line hacking to get you stuff copied over in
one direction host -> device. The examples/ directory contains a script
created for the Creative Zen Microphoto by Nicolas Tetreault.

Lost symbols
------------

Shared libraries can be troublesome to users not experienced with
them. The following is a condensed version of a generic question
that has appeared on the libmtp mailing list from time to time.

> PTP: Opening session
> Queried Creative Zen Vision:M
> gnomad2: relocation error: gnomad2: undefined symbol:
> LIBMTP_Get_Storageinfo
> (...)
> Are these type of errors related to libmtp or something else?

The problem is of a generic nature, and related to dynamic library
loading. It is colloquially known as "dependency hell".
(http://en.wikipedia.org/wiki/Dependency_hell)

The gnomad2 application calls upon the dynamic linker in Linux to
resolve the symbol "LIBMTP_Get_Storageinfo" or any other symbol
(ELF symbol, or link point or whatever you want to call them, a
symbol is a label on a memory address that the linker shall
resolve from label to actual address.)
For generic information on this subject see the INSTALL file and
this Wikipedia page:

http://en.wikipedia.org/wiki/Library_(computing)

When Linux /lib/ld-linux.so.X is called to link the symbols compiled
into gnomad2 (or any other executable using libmtp), it examines the
ELF file for the libmtp.so.X file it finds first and cannot resolve
the symbol "LIBMTP_Get_Storageinfo" (or whichever symbol you have a
problem witj) from it, since it's probably not there. There are many
possible causes of this symbol breakage:

1) You installed precompiled libmtp and gnomad2 packages (RPMs, debs
whatever) that do not match up. Typical cause: your gnomad2 package was
built against a newer version of libmtp than what's installed on your
machine. Another typical cause: you installed a package you found on
the web, somewhere, the dependency resolution system did not protest
properly (as it should) or you forced it to install anyway, ignoring
some warnings.

2) You compiled libmtp and/or gnomad2 from source, installing both or
either in /usr/local/lib and /usr/local/bin. This means at compile-time
gnomad2 finds the libmtp library in /usr/local/lib but at runtime, it
depends on the Linux system wide library loader (/lib/ld-linux.so.X) in
order to resolve the symbols. This loader will look into the file
/etc/ld.so.conf and/or the folder /etc/ld.so.conf.d in order to find
paths to libraries to be used for resolving the symbols. If you have
some older version of libmtp in e.g. /usr/lib (typically installed by a
package manager) it will take precedence over the new version you just
installed in /usr/local/lib and the newly compiled library in
/usr/local/lib will *not* be used, resulting in this error message.

3) You really did install the very latest versions (as of writing libmtp
0.1.5 and gnomad2 2.8.11) from source and there really is no
pre-installed package of either on your machine. In that case I'm
totally lost, I have no idea what's causing this.

Typical remedies:

1) If you don't want to mess around with your system and risk these
situations, only use pre-packaged software that came with the
distribution or its official support channels. If it still breaks,
blame your distribution, they're not packaging correctly. Relying on
properly packaged software and not installing things yourself *is* the
Linux solution to the "dependency hell" problem.

2) Read about dynamically linked library handling until the stuff I wrote
about in the previous list sounds like music to your ears, inspect
your /lib, /usr/lib, /usr/local/lib, /etc/ld.so.conf and the
/etc/ld.so.conf.d, remove all pre-packed versions using RPM, APT,
YaST or whatever your distribution uses, compile libmtp and gnomad2
(or whatever) from source only and you will be enlighted.

I don't know if this helps you, it's the best answer we can give.

API is obscure - I want plain files!
------------------------------------

PTP/MTP devices does not actually contain "files", they contain
objects. These objects have file names, but that is actually
just a name tag on the object.

Folders/directories aren't really such entities: they are just
objects too, albeit objects that can act as parent to other
objects. They are called "associations" and are created in atomic
fashion and even though there is an MTP command to get all the
associations of a certain object, this command is optional
so it is perfectly possible (and most common, actually) to create
devices where the "folders" (which are actually associations) have
no idea whatsoever of what files they are associated as parents to
(i.e. which files they contain). This is very easy for device
manufacturers to implement, all the association (i.e. finding out
which files are in a certain folder) has to be done by the MTP
Initiator / host computer.

Moving a file to a new folder is for example very simple in a
"real" file system. In PTP/MTP devices it is often not even possible,
some devices *may* be able to do that, if they support command
0x1019 "Move Object", but actually the only reliable way of executing
file movement is to upload the file to the host, download it with
the new parent, then delete the old file. We have played with the
idea of implementing this time consuming function as a fallback
in case the device does not support command 0x1019, perhaps one day
we will do that. (Some devices also support command 0x101a
"Copy Object".)

Then the issue that in PTP/MTP it is legal for two files to have
exactly the same path as long as their object IDs differ. A
folder/association can contain two files with the exact same name.
(And on the Creative devices this even works, too, though most devices
implicitly fail at this.) Perhaps one could add some custom hook for
handling that, so they become /Foo.mp3 and /Foo.mp3(1) or something
similar, but it's really a bit kludgy.

Playlists and albums aren't really files, thinking about
them as files like the hacks in libgphoto2 is really backwards. They are
called associations and are more like a symbolic link that links in a
star-shaped pattern to all the files that are part of the album/playlist.
Some devices (Samsung) thought that was too complicated and have a
different way of storing playlists in an UTF-16 encoded .spl-like file
instead! This is why playlists/albums must have their own structs and
functions.

Plain file access also assumes to be able to write files of an
undetermined size, which is simply not possible in a transactional
file system like PTP/MTP. (See further below.)

I Want Streaming!
-----------------

Streaming reads is easy. Just connect the output file descriptor from
LIBMTP_Get_File_To_File_Descriptor() (and a similar function for tracks)
wherever you want.

People have connected this to TCP sockets for streaming web servers
etc, works like a charm. Some devices will even survive if the callback
functions return non-zero and cancel the download. Some devices will
lock up and even require a reset if you do that. Devices are poorly
implemented so that's life. If you want to stream off a device, the
best idea is always to stream the entire file and discard the stuff
at the end you don't want. It will incur a delay if you e.g. want to
skip between tracks, sadly.

Then we get to the complicated things: streaming WRITES...

There is a function:
LIBMTP_Send_File_From_File_Descriptor() (and similar for tracks)
which will write a file to a device from a file descriptor, which may
be a socket or whatever.

HOWEVER: this requires a piece of metadata with the .filesize properly
set first.

This is not because we think it is funny to require that, the protocol
requires it. The reason is that PTP/MTP is a transactional file system
and it wants to be able to deny file transfer if the file won't fit on
the device, so the transaction never even starts, it's impossible to
start a transaction without giving file length.

People really want streaming so I tried a lot of hacks to see if they
would work, such as setting file size to 0xffffffffU or something other
unnaturally big and then aborting the file transfer when the stream ends.
It doesn't work: either the device crashes or the file simply disappears
since the device rolls back all failed transactions.

So this is an inherent limitation of the PTP/MTP protocol.

I want to remote control my device!
-----------------------------------

I have both good and bad news for you.

The good news is that the MTP protocol has well-defined commands to play
back content on a device. Operation 0xD411 (PTP_DPC_MTP_PlaybackObject)
will start playing back a file on the device (whatever that may mean if
this is not a music or video file), and operation 0xD403 can set the
playback volume to save your ears. Then there are operations to
determine how far into the current file you currently are, so as to
support say progress bars.

Since these commands have been around since the dawn of the MTP protocol
and since it was developed in cooperation with Creative Technology, this
is probably a requested feature from the Creative people who already had
support for playback on their devices using the PDE protocol back then.

Anyway, here are the bad news:
[logs]$ grep d411 *
mtp-detect-trekstor-vibez.txt: 0xd411: Playback Object

Aha there is only one known device in the world which actually supports
playback on the device. So either you go buy the Trekstor Vibez, or you
can forget about this. You could always try asking your hardware vendor
of choice to go implement this.

Since none of the core developers of libmtp has the Trekstor device, this
is not yet implemented in libmtp.

I make MTP devices!
-------------------

If you are a device vendor there is a lot you can do for libmtp:

* Please consider assigning one of your employees as a contact person
for libmtp, have them sign up to the libmtp development list and answer
questions and post new device ID:s as they are released to our
mailing list.

* If you want to help even more, assign someone to look deeper into
error reports on your specific devices, understand why your firmware
may require some special device flags and what can be done about it.

* Do you have spare devices you can give us? Send them to Richard (Mac
support) or Linus (Linux support). (So far nobody did that except for
Microsoft who sent us a Zune by proxy!)

Vendors do need help from libmtp too, especially we want to help
vendors improve their MTP stacks, because they all suffer from the
same problem: the lack of a proper conformance test has made many devices
incompliant with the MTP specification as it is published today: most
devices are just compliant with the Windows MTP stack, and don't work
out-of-the-box with libmtp. We need someone on the inside to help in
bug reporting vendors MTP stacks internally so these issues are raised.
A good way to go toward better MTP compliance is to test with an
alternative implementation of the stack. In e.g. IETF standardization
it is compulsory for an RFC to have atleast two independent implementations
for it to reach the status as standard.

Being compliant with libmtp is also more and more important for
vendors: libmtp is being deployed in some embedded systems like
set-top-boxes etc. It will be very irritating for customers if a device
will not dock properly with some home entertainment equipment just because
it is based on Linux and libmtp and not the Windows MTP stack.

Autodetect with gudev
---------------------

Previously you would use HAL to detect devices being plugged in. Nowadays
we use udev directly, or though the GNOME libgudev library. LIBMTPs
default udev rules export the proper properties to detect any MTP device
automatically, here is a verbose example derived from gnomad2:

#define G_UDEV_API_IS_SUBJECT_TO_CHANGE
#include <gudev/gudev.h>
const char * const gudev_subsystems[] = { "usb", NULL };
GUdevClient *gudev_client;
guint uevent_id;
guint uevent_bus_hooked = 0;
guint uevent_device_hooked = 0;

static void uevent_cb(GUdevClient *client, const char *action, GUdevDevice *device, void *data)
{
guint64 devicenum;
guint vendor;
guint model;
guint busnum;
guint devnum;
guint mtpdevice;

devicenum = (guint64) g_udev_device_get_device_number(device);
g_print("%s event for %s (%"G_GINT64_MODIFIER"x)", action,
g_udev_device_get_sysfs_path (device), devicenum);

/* get device info */
vendor = get_property_as_int(device, "ID_VENDOR_ID", 16);
model = get_property_as_int(device, "ID_MODEL_ID", 16);
busnum = get_property_as_int(device, "BUSNUM", 10);
devnum = get_property_as_int(device, "DEVNUM", 10);
mtpdevice = get_property_as_int(device, "ID_MTP_DEVICE", 10);

if (vendor == 0 || model == 0) {
g_print("couldn't get vendor or model ID for device at (%x:%x)\n",
busnum, devnum);
return;
} else {
g_print("vendor = %x, model = %x, bus = %x, device = %x\n",
vendor, model, busnum, devnum);
}

if (mtpdevice) {
g_print("device is MTP compliant\n");

if (g_str_equal(action, "add") &&
uevent_bus_hooked == 0 &&
uevent_device_hooked == 0) {
g_print(MTP device plugged in!\n");
uevent_bus_hooked = busnum;
uevent_device_hooked = devnum;
scan_jukebox(NULL);
} else if (g_str_equal (action, "remove") &&
uevent_bus_hooked == busnum &&
uevent_device_hooked == devnum) {
g_print("MTP device removed!\n");
uevent_bus_hooked = 0;
uevent_device_hooked = 0;
}
}
}

(...)
/*
* Monitor udev device events - we're only really interested in events
* for USB devices.
*/
gudev_client = g_udev_client_new(gudev_subsystems);
uevent_id = g_signal_connect_object(gudev_client,
"uevent",
G_CALLBACK(uevent_cb),
NULL, 0);

SKETCH OF AN OVERVIEW
---------------------

Draft agenda for a talk on MTP devices submitted for the Android
builders summit, might come to recycle this:

- Protocol overview
- Transactional filesystem - no corruption due to unplugged cables!
- libmtp interface
- relation to libgphoto2
- User expectations fall short:
- Not really a mountable filesystem.
- Streaming does not work. (Size needs to be known beforehand due to
transactional nature.)
- Device sins
- Android bugs
- Samsungs special Android MTP stack
- SonyEricsson Aricent stack for Xperia Androids pre 4.0, broken headers!
- Flat access model vs hierarchical, how Android uses MTP as an hierachical
file system while it was previously a flat database.
- Detecting from vendor extension, can fix in newer extensions!
- Autoprobing on Linux
- Color devices do not like autoprobing
- Devices need different PIDs for every alternative interface due to
the Windows USB stack.
- Multimode USB - one PID for each mode due to Windows limitations not
applicable to Linux, SONY devices have ~5 different PIDs for a single
device.
- Mode switch devices?
- MTPZ
- Ideas??

libmtp-zune's People

Contributors

Stargazers

Watchers

Forkers

sanyaade-research-hub radagaal dzheyneyr amped126 vinids86 landno jemc phantomski parastoo-62 jonghong storchi sgastudio dinkin heyitstim neoaksa gnashokkumar

libmtp-zune's Issues

Doesn't compile anymore

Running libtoolize
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
Removing aclocal cruft
Running aclocal -I ./m4 
configure.ac:7: error: 'AM_CONFIG_HEADER': this macro is obsolete.
    You should use the 'AC_CONFIG_HEADERS' macro instead.
/usr/share/aclocal-1.13/obsolete-err.m4:12: AM_CONFIG_HEADER is expanded from...
configure.ac:7: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1
Last command failed with status 1 in directory /tmp/yaourt-tmp-rax/aur-libmtp-zune/src/libmtp-zune-build.
Aborting
`

Unable to send files to Zune 8

Hi,

I installed this package instead of libmtp and I'm trying to use programs like gMTP or Rhythmbox to send files to my Zune. With gMTP I'm able to detect, list files and navigate my Zune. But I get "Error getting file from MTP device." when I try to copy them to my computer and fail to create anything on it.

Am I missing something?

UNKNOWN Device

Device 0 (VID=0fce and PID=01c5) is UNKNOWN.
Please report this VID/PID and the device model to the libmtp development team
Device with name: Xperia E4 Dual

As you asked ;-) Thanks

Can't compile anymore

Hi,

Has something significant changed resulting in compile failure?

Removing libtool cruft
Running libtoolize
libtoolize: putting auxiliary files in .'. libtoolize: copying file./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, m4'. libtoolize: copying filem4/libtool.m4'
libtoolize: copying file m4/ltoptions.m4' libtoolize: copying filem4/ltsugar.m4'
libtoolize: copying file m4/ltversion.m4' libtoolize: copying filem4/lt~obsolete.m4'
Removing aclocal cruft
Running aclocal -I ./m4
Removing autoheader cruft
Running autoheader
Removing automake cruft
Running automake
configure.ac:13: installing './config.guess'
configure.ac:13: installing './config.sub'
configure.ac:5: installing './install-sh'
configure.ac:5: installing './missing'
examples/Makefile.am: installing './depcomp'
Removing autoconf cruft
Running autoconf
Autoupdate config.sub and config.guess (y/n)?
y
Warning: wildcards not supported in HTTP.
--2012-08-01 15:51:29-- http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess
Resolving savannah.gnu.org... 140.186.70.70
Connecting to savannah.gnu.org|140.186.70.70|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://cvs.savannah.gnu.org/viewvc/*checkout*/config/config/config.guess [following]
Warning: wildcards not supported in HTTP.
--2012-08-01 15:51:29-- http://cvs.savannah.gnu.org/viewvc/*checkout*/config/config/config.guess
Resolving cvs.savannah.gnu.org... 140.186.70.72
Connecting to cvs.savannah.gnu.org|140.186.70.72|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: `tmpfile'

[   <=>                                            ] 44,892      83.8K/s   in 0.5s

2012-08-01 15:51:30 (83.8 KB/s) - `tmpfile' saved [44892]

Warning: wildcards not supported in HTTP.
--2012-08-01 15:51:30-- http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub
Resolving savannah.gnu.org... 140.186.70.70
Connecting to savannah.gnu.org|140.186.70.70|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://cvs.savannah.gnu.org/viewvc/*checkout*/config/config/config.sub [following]
Warning: wildcards not supported in HTTP.
--2012-08-01 15:51:31-- http://cvs.savannah.gnu.org/viewvc/*checkout*/config/config/config.sub
Resolving cvs.savannah.gnu.org... 140.186.70.72
Connecting to cvs.savannah.gnu.org|140.186.70.72|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: `tmpfile'

[  <=>                                             ] 33,387      64.4K/s   in 0.5s

2012-08-01 15:51:32 (64.4 KB/s) - `tmpfile' saved [33387]

Finished!
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking whether ln -s works... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert i686-pc-linux-gnu file names to i686-pc-linux-gnu format... func_convert_file_noop
checking how to convert i686-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... dlltool
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @file support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for working iconv... yes
checking for iconv declaration...
extern size_t iconv (iconv_t cd, char * inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
configure: API documentation will not be generated
checking if the host operating system is Darwin... no
checking if the host operating system is Linux... yes
checking For MinGW32... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for LIBUSB... yes
checking for libgcrypt... checking for gcry_check_version in -lgcrypt... yes
configure: MTPZ functionality enabled
configure: ** using libusb 1.0.12 ***
checking for ANSI C header files... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking ctype.h usability... yes
checking ctype.h presence... yes
checking for ctype.h... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking getopt.h usability... yes
checking getopt.h presence... yes
checking for getopt.h... yes
checking libgen.h usability... yes
checking libgen.h presence... yes
checking for libgen.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking stdio.h usability... yes
checking stdio.h presence... yes
checking for stdio.h... yes
checking for string.h... (cached) yes
checking for sys/stat.h... (cached) yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking byteswap.h usability... yes
checking byteswap.h presence... yes
checking for byteswap.h... yes
checking sys/uio.h usability... yes
checking sys/uio.h presence... yes
checking for sys/uio.h... yes
checking for an ANSI C-conforming const... yes
checking for off_t... yes
checking return type of signal handlers... void
checking for size_t... yes
checking for struct stat.st_blksize... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for working memcmp... yes
checking whether lstat correctly handles trailing slash... yes
checking whether stat accepts an empty string... no
checking for basename... yes
checking for memset... yes
checking for select... yes
checking for strdup... yes
checking for strerror... yes
checking for strndup... yes
checking for strrchr... yes
checking for strtoul... yes
checking for usleep... yes
checking for mkstemp... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for uint8_t in stdint.h... yes
checking whether byte ordering is bigendian... no
checking for le32toh in machine/endian.h... no
checking for ntohl in arpa/inet.h... yes
checking for swap32 in machine/endian.h... no
checking for bswap_32 in byteswap.h... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating src/libmtp.h
config.status: creating doc/Doxyfile
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating src/Makefile
config.status: creating examples/Makefile
config.status: creating util/Makefile
config.status: creating libmtp.sh
config.status: creating hotplug.sh
config.status: creating libmtp.pc
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
make all-recursive
make[1]: Entering directory /home/rax/Building/ABS/libmtp-zune/src/libmtp-zune-build' Making all in src make[2]: Entering directory/home/rax/Building/ABS/libmtp-zune/src/libmtp-zune-build/src'
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-libmtp.lo -MD -MP -MF .deps/libmtp_la-libmtp.Tpo -c -o libmtp_la-libmtp.lo test -f 'libmtp.c' || echo './'libmtp.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-libmtp.lo -MD -MP -MF .deps/libmtp_la-libmtp.Tpo -c libmtp.c -fPIC -DPIC -o .libs/libmtp_la-libmtp.o
libmtp.c: In function 'LIBMTP_Read_Event':
libmtp.c:2154:12: warning: variable 'param3' set but not used [-Wunused-but-set-variable]
libmtp.c:2153:12: warning: variable 'param2' set but not used [-Wunused-but-set-variable]
libmtp.c:2152:12: warning: variable 'param1' set but not used [-Wunused-but-set-variable]
libmtp.c:2151:12: warning: variable 'transaction_id' set but not used [-Wunused-but-set-variable]
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-libmtp.lo -MD -MP -MF .deps/libmtp_la-libmtp.Tpo -c libmtp.c -o libmtp_la-libmtp.o >/dev/null 2>&1
mv -f .deps/libmtp_la-libmtp.Tpo .deps/libmtp_la-libmtp.Plo
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-unicode.lo -MD -MP -MF .deps/libmtp_la-unicode.Tpo -c -o libmtp_la-unicode.lo test -f 'unicode.c' || echo './'unicode.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-unicode.lo -MD -MP -MF .deps/libmtp_la-unicode.Tpo -c unicode.c -fPIC -DPIC -o .libs/libmtp_la-unicode.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-unicode.lo -MD -MP -MF .deps/libmtp_la-unicode.Tpo -c unicode.c -o libmtp_la-unicode.o >/dev/null 2>&1
mv -f .deps/libmtp_la-unicode.Tpo .deps/libmtp_la-unicode.Plo
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-util.lo -MD -MP -MF .deps/libmtp_la-util.Tpo -c -o libmtp_la-util.lo test -f 'util.c' || echo './'util.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-util.lo -MD -MP -MF .deps/libmtp_la-util.Tpo -c util.c -fPIC -DPIC -o .libs/libmtp_la-util.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-util.lo -MD -MP -MF .deps/libmtp_la-util.Tpo -c util.c -o libmtp_la-util.o >/dev/null 2>&1
mv -f .deps/libmtp_la-util.Tpo .deps/libmtp_la-util.Plo
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-playlist-spl.lo -MD -MP -MF .deps/libmtp_la-playlist-spl.Tpo -c -o libmtp_la-playlist-spl.lo test -f 'playlist-spl.c' || echo './'playlist-spl.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-playlist-spl.lo -MD -MP -MF .deps/libmtp_la-playlist-spl.Tpo -c playlist-spl.c -fPIC -DPIC -o .libs/libmtp_la-playlist-spl.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-playlist-spl.lo -MD -MP -MF .deps/libmtp_la-playlist-spl.Tpo -c playlist-spl.c -o libmtp_la-playlist-spl.o >/dev/null 2>&1
mv -f .deps/libmtp_la-playlist-spl.Tpo .deps/libmtp_la-playlist-spl.Plo
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-ptp.lo -MD -MP -MF .deps/libmtp_la-ptp.Tpo -c -o libmtp_la-ptp.lo test -f 'ptp.c' || echo './'ptp.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-ptp.lo -MD -MP -MF .deps/libmtp_la-ptp.Tpo -c ptp.c -fPIC -DPIC -o .libs/libmtp_la-ptp.o
ptp.c: In function 'ptp_nikon_writewifiprofile':
ptp.c:2612:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
ptp.c:2614:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-ptp.lo -MD -MP -MF .deps/libmtp_la-ptp.Tpo -c ptp.c -o libmtp_la-ptp.o >/dev/null 2>&1
mv -f .deps/libmtp_la-ptp.Tpo .deps/libmtp_la-ptp.Plo
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-mtpz.lo -MD -MP -MF .deps/libmtp_la-mtpz.Tpo -c -o libmtp_la-mtpz.lo test -f 'mtpz.c' || echo './'mtpz.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libusb-1.0 -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -MT libmtp_la-mtpz.lo -MD -MP -MF .deps/libmtp_la-mtpz.Tpo -c mtpz.c -fPIC -DPIC -o .libs/libmtp_la-mtpz.o
mtpz.c:976:61: error: 'r' undeclared here (not in a function)
mtpz.c:977:2: error: expected '}' before numeric constant
make[2]: *** [libmtp_la-mtpz.lo] Error 1
make[2]: Leaving directory /home/rax/Building/ABS/libmtp-zune/src/libmtp-zune-build/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/home/rax/Building/ABS/libmtp-zune/src/libmtp-zune-build'
make: *** [all] Error 2

Sending "application cetificate message" fails

When I run any mtp-* utility, I've noticed I get the following error when trying to detect/connect/send files to my Dell Venue Pro Windows Phone 7.5:

Device 0 (VID=045e and PID=04ec) is a Microsoft Windows Phone.
MTPZ device detected. Authenticating...
(MTPZ) Setting session initiator info: success.
(MTPZ) Resetting handshake: success.
(MTPZ) Sending application certificate message: failure.

After those messages, I receive failures based on whichever task I was attempting. Not sure what to try next. Great work, though, and I'm glad someone is hacking on this!

Loading ~/.mtpz-data makes packaging difficult

It would be much easier to package libmtp-zune if it could look in a configurable place (like, say, /usr/share/libmtp-zune/mtpz-data) for the mtpz-data file instead of in the home directory.

Unable to mtp-detect a Lumia 800

Hi,

I'm trying to get signs of life from my Lumia 800 WP7 device.

I'm not seeing any evidence that the MTPZ handshake is even being attempted, even though the microsoft.com/MTPZ string is definitely being received from the device:

directhex@dream:~/Projects/libmtp-zune$ sudo LIBMTP_DEBUG=12 /opt/zune/bin/mtp-detect
LIBMTP_Set_Debug: Setting debugging level to 12 (on)
libmtp version: 1.1.2

Listing raw device(s)
usb_set_debug: Setting debugging level to 9 (on)
usb_os_init: Found USB VFS at /dev/bus/usb
usb_os_find_busses: Found 002
usb_os_find_busses: Found 001
usb_os_find_devices: Found 008 on 002
usb_os_find_devices: Found 004 on 002
skipped 5 class/vendor specific interface descriptors
skipped 6 class/vendor specific interface descriptors
skipped 5 class/vendor specific interface descriptors
usb_os_find_devices: Found 002 on 002
usb_os_find_devices: Found 001 on 002
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
usb_os_find_devices: Found 046 on 001
skipping descriptor 0x21
skipped 1 class/vendor specific endpoint descriptors
usb_os_find_devices: Found 045 on 001
usb_os_find_devices: Found 044 on 001
skipped 1 class/vendor specific interface descriptors
skipped 1 class/vendor specific interface descriptors
usb_os_find_devices: Found 043 on 001
skipped 1 class/vendor specific interface descriptors
skipped 1 class/vendor specific interface descriptors
usb_os_find_devices: Found 042 on 001
usb_os_find_devices: Found 041 on 001
usb_os_find_devices: Found 006 on 001
skipping descriptor 0xB
skipped 1 class/vendor specific endpoint descriptors
skipped 5 class/vendor specific interface descriptors
skipping descriptor 0x25
skipped 1 class/vendor specific endpoint descriptors
skipped 19 class/vendor specific interface descriptors
usb_os_find_devices: Found 005 on 001
usb_os_find_devices: Found 004 on 001
skipped 1 class/vendor specific interface descriptors
usb_os_find_devices: Found 003 on 001
usb_os_find_devices: Found 002 on 001
usb_os_find_devices: Found 001 on 001
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
USB error: error sending control message: Broken pipe
USB error: could not clear/halt ep 0: No such file or directory
USB error: error sending control message: Broken pipe
USB error: could not clear/halt ep 0: No such file or directory
LIBMTP LIBMTP_Detect_Raw_Devices[672]: Device 0 (VID=045e and PID=04ec) is a Microsoft Windows Phone.
Found 1 device(s):
Microsoft: Windows Phone (045e:04ec) @ bus 2, dev 8
Attempting to connect device(s)
usb_set_debug: Setting debugging level to 9 (on)
usb_os_init: Found USB VFS at /dev/bus/usb
usb_os_find_busses: Found 002
usb_os_find_busses: Found 001
usb_os_find_devices: Found 008 on 002
usb_os_find_devices: Found 004 on 002
skipped 5 class/vendor specific interface descriptors
skipped 6 class/vendor specific interface descriptors
skipped 5 class/vendor specific interface descriptors
usb_os_find_devices: Found 002 on 002
usb_os_find_devices: Found 001 on 002
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
usb_os_find_devices: Found 046 on 001
skipping descriptor 0x21
skipped 1 class/vendor specific endpoint descriptors
usb_os_find_devices: Found 045 on 001
usb_os_find_devices: Found 044 on 001
skipped 1 class/vendor specific interface descriptors
skipped 1 class/vendor specific interface descriptors
usb_os_find_devices: Found 043 on 001
skipped 1 class/vendor specific interface descriptors
skipped 1 class/vendor specific interface descriptors
usb_os_find_devices: Found 042 on 001
usb_os_find_devices: Found 041 on 001
usb_os_find_devices: Found 006 on 001
skipping descriptor 0xB
skipped 1 class/vendor specific endpoint descriptors
skipped 5 class/vendor specific interface descriptors
skipping descriptor 0x25
skipped 1 class/vendor specific endpoint descriptors
skipped 19 class/vendor specific interface descriptors
usb_os_find_devices: Found 005 on 001
usb_os_find_devices: Found 004 on 001
skipped 1 class/vendor specific interface descriptors
usb_os_find_devices: Found 003 on 001
usb_os_find_devices: Found 002 on 001
usb_os_find_devices: Found 001 on 001
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x1002, Open session
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1000 0000 0100 0210 0000 0000 0100 0000 ................
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0xffffff92
LIBMTP ptp_usb_getresp[1490]: 02ff
LIBMTP configure_usb_device[1983]: PTP_ERROR_IO: failed to open session, trying again after resetting USB interface
LIBMTP configure_usb_device[1984]: LIBMTP libusb: Attempt to reset device
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x1002, Open session
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1000 0000 0100 0210 0000 0000 0100 0000 ................
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0000 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x1001, get device info
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 0c00 0000 0100 0110 0100 0000 ............
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 9303 0000 0200 0110 0100 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0387 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0387 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0387
LIBMTP ptp_read_func[878]: <==USB IN
0000: 6400 0600 0000 6400 9a6d 0069 0063 0072 d.....d..m.i.c.r
0010: 006f 0073 006f 0066 0074 002e 0063 006f .o.s.o.f.t...c.o
0020: 006d 003a 0020 0031 002e 0030 003b 0020 .m.:. .1...0.;.
0030: 006d 0069 0063 0072 006f 0073 006f 0066 .m.i.c.r.o.s.o.f
0040: 0074 002e 0063 006f 006d 002f 0057 004d .t...c.o.m./.W.M
0050: 0044 0052 004d 0050 0044 003a 0020 0031 .D.R.M.P.D.:. .1
0060: 0030 002e 0031 003b 0020 006d 0069 0063 .0...1.;. .m.i.c
0070: 0072 006f 0073 006f 0066 0074 002e 0063 .r.o.s.o.f.t...c
0080: 006f 006d 002f 0057 004d 0050 0050 0044 .o.m./.W.M.P.P.D
0090: 003a 0020 0031 0031 002e 0031 003b 0020 .:. .1.1...1.;.
00a0: 006d 0069 0063 0072 006f 0073 006f 0066 .m.i.c.r.o.s.o.f
00b0: 0074 002e 0063 006f 006d 002f 0041 0041 .t...c.o.m./.A.A
00c0: 0056 0054 003a 0020 0031 002e 0030 003b .V.T.:. .1...0.;
00d0: 0020 006d 0069 0063 0072 006f 0073 006f . .m.i.c.r.o.s.o
00e0: 0066 0074 002e 0063 006f 006d 002f 0057 .f.t...c.o.m./.W
00f0: 004d 0044 0052 004d 004e 0044 003a 0020 .M.D.R.M.N.D.:.
0100: 0031 002e 0030 003b 0020 006d 0069 0063 .1...0.;. .m.i.c
0110: 0072 006f 0073 006f 0066 0074 002e 0063 .r.o.s.o.f.t...c
0120: 006f 006d 002f 004d 0054 0050 005a 003a .o.m./.M.T.P.Z.:
0130: 0020 0031 002e 0030 003b 0000 0000 0060 . .1...0.;..... 0140: 0000 0001 1002 1003 1004 1005 1006 1007 ................ 0150: 1008 1009 100b 100c 100d 100f 1010 1013 ................ 0160: 1014 1015 1016 1019 101b 1010 9811 9802 ................ 0170: 9807 9801 9803 9804 9805 9806 9808 9829 ...............) 0180: 922a 922e 922f 9230 9231 9201 9102 9103 .*.../.0.1...... 0190: 9104 9105 9106 9107 9108 9109 910a 910b ................ 01a0: 9118 9219 9204 9217 9232 9233 9212 9213 .........2.3.... 01b0: 9214 9215 9216 9220 9221 9222 9223 9208 ....... .!.".#.. 01c0: 6101 6102 6103 6104 6105 6106 6109 610a a.a.a.a.a.a.a.a. 01d0: 610b 610d 6107 6100 9301 9306 9302 9303 a.a.a.a......... 01e0: 9304 9305 930b 930c 930d 930e 9312 9313 ................ 01f0: 9314 9360 9361 9362 9363 9364 9365 9366 ....a.b.c.d.e.f
0200: 9334 9204 0000 000c 4003 4001 c702 c736 .4......@[email protected]
0210: 0000 0001 d301 d521 d201 d101 d401 5002 .......!......P.
0220: d302 d102 d402 5019 d238 d218 d20f d32f ......P..8...../
0230: d205 d305 d425 d21c d226 d206 d437 d217 .....%...&...7..
0240: d203 d11a d232 d235 d233 d234 d21b d21f .....2.5.3.4....
0250: d200 d300 d120 d230 d207 d327 d208 d328 ..... .0...'...(
0260: d20a d32a d20b d32b d20c d32c d209 d329 ..._...+...,...)
0270: d20d d32d d20e d32e d231 d204 d336 d200 ...-.....1...6..
0280: 0000 0011 0000 0018 b20b ba01 b400 3011 ..............0.
0290: b205 ba03 ba01 3001 3881 b982 b916 b203 ......0.8.......
02a0: b915 b20c 3001 b909 3006 4e00 4f00 4b00 ....0...0.N.O.K.
02b0: 4900 4100 0000 0a4c 0075 006d 0069 0061 I.A....L.u.m.i.a
02c0: 0020 0038 0030 0030 0000 002d 3000 3700 . .8.0.0...-0.7.
02d0: 2e00 3100 3000 2e00 3000 3700 3700 3400 ..1.0...0.7.7.4.
02e0: 3000 2e00 3000 3300 2d00 3000 3000 2e00 0...0.3.-.0.0...
02f0: 3000 3000 2e00 3000 3000 3000 3000 3000 0.0...0.0.0.0.0.
0300: 2e00 3000 3000 2d00 3000 3000 2e00 3000 ..0.0.-.0.0...0.
0310: 3000 2e00 3000 3000 3000 3000 3000 2e00 0...0.0.0.0.0...
0320: 3000 3000 0000 2a64 0032 0034 0033 0030 0.0..._d.2.4.3.0
0330: 0038 0037 0033 0020 002d 0020 0036 0036 .8.7.3. .-. .6.6
0340: 0036 0030 0037 0039 0038 0032 0020 002d .6.0.7.9.8.2. .-
0350: 0020 0036 0039 0036 0065 0066 0037 0033 . .6.9.6.e.f.7.3
0360: 0066 0020 002d 0020 0037 0032 0062 0037 .f. .-. .7.2.b.7
0370: 0038 0031 0035 0066 0000 0000 0000 0000 .8.1.5.f........
0380: 0000 0000 0000 00 .......
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0100 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 0200 0000 04dc 0000 ................
0010: 18b2 0000 ....
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 0200 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0200 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 0300 0000 04dc 0000 ................
0010: 0bba 0000 ....
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 0300 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0300 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 0400 0000 04dc 0000 ................
0010: 01b4 0000 ....
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 0400 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0400 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 0500 0000 04dc 0000 ................
0010: 0030 0000 .0..
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 0500 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0500 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 0600 0000 04dc 0000 ................
0010: 11b2 0000 ....
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 0600 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0600 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 0700 0000 04dc 0000 ................
0010: 05ba 0000 ....
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 0700 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0700 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 0800 0000 04dc 0000 ................
0010: 03ba 0000 ....
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 0800 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0800 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 0900 0000 04dc 0000 ................
0010: 0130 0000 .0..
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 0900 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0900 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 0a00 0000 04dc 0000 ................
0010: 0138 0000 .8..
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 0a00 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0a00 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 0b00 0000 04dc 0000 ................
0010: 81b9 0000 ....
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 0b00 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0b00 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 0c00 0000 04dc 0000 ................
0010: 82b9 0000 ....
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 0c00 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0c00 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 0d00 0000 04dc 0000 ................
0010: 16b2 0000 ....
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 0d00 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0d00 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 0e00 0000 04dc 0000 ................
0010: 03b9 0000 ....
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 0e00 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0e00 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 0f00 0000 04dc 0000 ................
0010: 15b2 0000 ....
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 0f00 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 0f00 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 1000 0000 04dc 0000 ................
0010: 0c30 0000 .0..
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 1000 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 1000 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 1100 0000 04dc 0000 ................
0010: 01b9 0000 ....
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 1100 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 1100 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x9802, Get object property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1400 0000 0100 0298 1200 0000 04dc 0000 ................
0010: 0930 0000 .0..
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 1e00 0000 0200 0298 1200 0000 ............
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0012 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0012 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x0012
LIBMTP ptp_read_func[878]: <==USB IN
0000: 04dc 0800 0000 0000 0000 0000 0002 0000 ................
0010: 0000 ..
LIBMTP ptp_usb_getresp[1463]: RESPONSE: LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0120 1200 0000 ....... ....
LIBMTP ptp_usb_getresp[1490]: 2001
LIBMTP ptp_usb_sendreq[1149]: REQUEST: 0x1014, Get device property description
LIBMTP ptp_write_func[984]: USB OUT==>
0000: 1000 0000 0100 1410 1300 0000 0150 0000 .............P..
LIBMTP ptp_usb_getdata[1286]: GET DATA PHASE
LIBMTP ptp_read_func[840]: Remaining size to read: 0x0200 bytes
LIBMTP ptp_read_func[864]: Reading in 0x0200 bytes
LIBMTP ptp_read_func[872]: Result of read: 0x000c
LIBMTP ptp_read_func[878]: <==USB IN
0000: 0c00 0000 0300 0f20 1300 0000 ....... ....

kbhomes / libmtp-zune Goto Github PK

libmtp-zune's Introduction

libmtp-zune's People

Contributors

Stargazers

Watchers

Forkers

libmtp-zune's Issues

Doesn't compile anymore

Unable to send files to Zune 8

UNKNOWN Device

Can't compile anymore

Sending "application cetificate message" fails

Loading ~/.mtpz-data makes packaging difficult

Unable to mtp-detect a Lumia 800

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent