..12-Mar-20154 KiB

aclocal.m412-Mar-201579.3 KiB

AUTHORS12-Mar-20151.4 KiB

ChangeLog12-Mar-201590 KiB

config.guess12-Mar-201543.8 KiB

config.h12-Mar-20155.5 KiB

config.h.in12-Mar-20155.2 KiB


config.sub12-Mar-201532.6 KiB

configure12-Mar-2015519.7 KiB

configure.ac12-Mar-20153.5 KiB

COPYING12-Mar-201525.8 KiB

depcomp12-Mar-201518.2 KiB

doc/12-Mar-20154 KiB

examples/12-Mar-20154 KiB KiB

INSTALL12-Mar-20157.3 KiB

install-sh12-Mar-201513.3 KiB



libmtp.sh12-Mar-20151.2 KiB KiB

libmtp.xcodeproj/12-Mar-20154 KiB

ltmain.sh12-Mar-2015237.5 KiB

m4/12-Mar-20154 KiB




Makefile.in12-Mar-201525 KiB

missing12-Mar-201511.2 KiB

README12-Mar-201528.7 KiB KiB

src/12-Mar-20154 KiB

TODO12-Mar-20154.9 KiB


1Building and Installing
4See the "INSTALL" file.
10libmtp is based on several ancestors:
12* libptp2 by Mariusz Woloszyn was the starting point used
13  by Richard A. Low for the initial starter port. You can
14  find it at
16* libgphoto2 by Mariusz Woloszyn and Marcus Meissner was
17  used at a later stage since it was (is) more actively
18  maintained. libmtp tracks the PTP implementation in
19  libgphoto2 and considers it an upstream project. We will
20  try to submit anything generally useful back to libgphoto2
21  and not make double efforts. In practice this means we
22  use ptp.c, ptp.h and ptp-pack.c verbatim from the libgphoto2
23  source code. If you need to change things in these files,
24  make sure it is so general that libgphoto2 will want to
25  merge it to their codebase too. You find libgphoto2 as part
26  of gPhoto:
28* libnjb was a project that Richard and Linus were working
29  on before libmtp. When Linus took Richards initial port
30  and made an generic C API he re-used the philosophy and
31  much code from libnjb. Many of the sample programs are for
32  example taken quite literally from libnjb. You find it here:
36Contacting and Contributing
39See the project page at
40We always need your help. There is a mailinglist and a
41bug report system there.
43People who want to discuss MTP devices in fora seem to
44hang out on the forums at AnythingbutiPod:
48Compiling programs for libmtp
51libmtp has support for the pkg-config script by adding a libmtp.pc
52entry in $(prefix)/lib/pkgconfig. To compile a libmtp program,
53"just" write:
55gcc -o foo `pkg-config --cflags --libs libmtp` foo.c
57This also simplifies compilation using autoconf and pkg-config: just
58write e.g.
64To have libmtp LIBS and CFLAGS defined. Needless to say, this will
65only work if you have pkgconfig installed on your system, but most
66people have nowadays.
68If your library is installed in e.g. /usr/local you may have to tell
69this to pkgconfig by setting the PKG_CONFIG_PATH thus:
71export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
77Read the API documentation that can be generated with doxygen.
78It will be output in doc/html if you have Doxygen properly
79installed. (It will not be created unless you have Doxygen!)
81For information about the Media Transfer Protocol, see:
84The official 1.0 specification for MTP was released by the
85USB Implementers Forum in may, 2008. Prior to this, only a
86proprietary Microsoft version was available, and quite a few
87devices out there still use some aspects of the Microsoft
88version, which deviates from the specified standard. You can
89find the official specification here:
93The Examples
96In the subdirectory "examples" you find a number of 
97command-line tools, illustrating the use of libmtp in very
98simple terms.
100Please do not complain about the usability or documentation
101of these examples, they look like they do for two reasons:
1031. They are examples, not tools. If they were intended for
104   day-to-day usage by commandline freaks, I would have
105   called them "tools" not "examples".
1072. The MTP usage paradigm is that a daemon should hook
108   the device upon connection, and that it should be 
109   released by unplugging. GUI tools utilizing HAL (hald)
110   and D-Bus do this much better than any commandline
111   program ever can. (See below on bugs.) Specificationwise
112   this is a bug, however it is present in many, many
113   devices.
115That said, if you want to pick up and maintain the examples,
116please volunteer.
119New Devices
122If you happen upon a device which libmtp claims it cannot
123autodetect, please submit the vendor ID and device ID 
124(these can be obtained from the "lsusb" and "lsusb -n"
125commands run as root) as a bug, patch or feature request 
126on the Sourceforge bug tracker at our homepage. If it 
127gives a sensible  output from "mtp-detect" then please attach 
128the result as well as it teach us some stuff about your 
129device. If you've done some additional hacking, join our 
130mailinglist and post your experiences there.
132If you want to be able to hack some more and you're not
133afraid of C hacking, add an entry for your device's 
134vendor/product ID and a descriptive string to the database 
135in the file src/music-players.h.
137If you want to poke around to see if your device has some
138special pecularities, you can test some special device
139flags (defined in src/device-flags.h) by inserting them
140together with your device entry in src/music-players.h.
141Flags can be tested in isolation or catenated with "|"
142(binary OR). If relatives to your device use a certain
143flag, chances are high that a new device will need it
144too, typically from the same manufacturer.
146The most common flag that needs to be set is the 
147DEVICE_FLAG_UNLOAD_DRIVER that detach any Linux kernel
148drivers that may have attached to the device making
149MTP access impossible. This is however not expected to
150really work: this is a problem being tracked as of
151now (2007-08-04). See the "last resort" solutions below
152if you really need to get your dual-mode device to work 
153with MTP.
155Another flag which is easy to identify is the
156DEVICE_FLAG_NO_ZERO_READS, which remedies connection
157timeouts when getting files, and some timeouts on e.g. 
158successive "mtp-connect" calls.
160If you are a device vendor, please consider assigning one 
161of your employees as a contact person for libmtp, have them
162sign up to the libmtp development list and answer questions
163and post new device ID:s as they are released to our
164mailing list. By the way: do you have spare devices you
165can give us? Send them to Richard (Mac support) or Linus
166(Linux support). (So far nobody did that except for Microsoft
167who sent us a Zune by proxy!)
169If your device is very problematic we are curious of how it
170works under Windows, so we enjoy reading USB packet sniffs
171that reveal the low-level traffic carried out between
172Windows Media Player and your device. This can be done 
173using e.g.:
175* USBsnoop:
178* The trial version of HHD Softwares software-only
179  USB monitor. You need to get a copy of version 2.37 since
180  the newer trial versions won't let you carry out the 
181  needed packet sniffs. (As of 2007-03-10 a copy can be found
182  at:
184There are other USB monitors as well, some more expensive
185alternatives use hardware and even measure electronic
186characteristics of the traffic (which is far too much 
187detail for us).
189Device sniffs are an easy read since the PTP/MTP protocol
190is nicely structured. All commands will have a structure such
191as this in the log, we examplify with a object list request:
194000120: Bulk or Interrupt Transfer (UP), 03.09.2007 12:49:25.9843750 +0.0
195Pipe Handle: 0x863ce234 (Endpoint Address: 0x2)
196Send 0x20 bytes to the device:
197 20 00 00 00 01 00 05 98 23 00 00 00 27 03 00 10    ......?#...'...
198 Length      TYPE  CMD   Trans#      Param1
200 00 00 00 00 02 DC 00 00 00 00 00 00 00 00 00 00   .....Ü..........
201 Param2      Param3      Param4      Param5
204000121: Bulk or Interrupt Transfer (UP), 03.09.2007 12:49:26.0 +0.0156250
205Pipe Handle: 0x863ce214 (Endpoint Address: 0x81)
206Get 0x1a bytes from the device:
207 1A 00 00 00 02 00 05 98 23 00 00 00 01 00 00 00   .......?#.......
208 Length      TYPE  CMD   Trans#      DATA
210 27 03 00 10 02 DC 04 00 00 30                     '....Ü...0
213000122: Bulk or Interrupt Transfer (UP), 03.09.2007 12:49:26.0 +0.0
214Pipe Handle: 0x863ce214 (Endpoint Address: 0x81)
215Get 0xc bytes from the device:
216 0C 00 00 00 03 00 01 20 23 00 00 00               ....... #...
217 Length      TYPE  CODE  Trans#
219* One send (OUT to the device), two reads (IN from the device).
221* All three byte chunks commands are 
222  sent/recieved/recieeved by the function  ptp_transaction() 
223  in the file ptp.c.
225* It boils down to ptp_usb_sendreq(), optionally ptp_usb_senddata() 
226  or ptp_usb_getdata() and finally ptp_usb_getresp() in the file 
227  libusb-glue.c. Notice ptp_usb_sendreq() and ptp_usb_getresp()
228  are ALWAYS called. The TYPE field correspond to this, so the
229  TYPES in this case are "COMMAND" (0x0001), "DATA" (0x0002), 
230  and "RESPONSE" (0x0003).
232* Notice that the byte order is little endian, so you need to read
233  each field from right to left.
235* This COMMAND has:
236  CMD 0x99805, we see in ptp.h that this is PTP_OC_MTP_GetObjPropList.
237  Transaction# 0x00000023.
238  REQUEST parameters 0x10000327, 0x00000000, 0x0000DC02, 0x00000000
239    0x00000000, in this case it means "get props for object 0x10000327",
240    "any format", "property 0xDC02" (PTP_OPC_ObjectFormat), then two
241    parameters that are always zero (no idea what they mean or their
242    use).
244* The DATA has:
245  CMD 0x99805, we see in ptp.h that this is PTP_OC_MTP_GetObjPropList.
246  Transaction# 0x00000023.
247  Then comes data 0x00000001, 0x10000327, 0xDC02, 0x0004, 0x3000
248  Which means in this case, (and this is the tricky part) "here
249  you have 1 property", "for object 0x10000327", "it is property
250  0xDC02" (PTP_OPC_ObjectFormat), "which is of type 0x0004"
251  (PTP_DTC_UINT16), "and set to 0x3000" (PTP_OFC_Undefined, it
252  is perfectly valid to have undefined object formats, since it
253  is a legal value defining this).
255* This RESPONSE has:
256  CMD 0x99805, we see in ptp.h that this is PTP_OC_MTP_GetObjPropList.
257  Return Code ("RC") = 0x2001, PTP_RC_OK, all went fine.
258  Transaction# 0x00000023.  
260If you want to compare the Windows behaviour with a similar
261operation using libmtp you can go into the src/libusb-glue.c 
262file and uncomment the row that reads:
266(I.e. remove the two //.)
268This will make libmtp print out a hex dump of every bulk USB
269transaction. The bulk transactions contain all the PTP/MTP layer
270data, which is usually where the problems appear.
273Dual-mode devices does not work - last resort:
276Some devices that are dual-mode are simply impossible to get
277to work under Linux because the usb-storage(.ko) kernel
278module hook them first, and refuse to release them, even
279when we specify the DEVICE_FLAG_UNLOAD_DRIVER flag. (Maybe
280it DOES release it but the device will immediately be probed
281at the USB mass storage interface AGAIN because it 
284Here is what some people do:
286 1. Plug in the device.
287 2. USB-mass storage folder will open automatically.
288 3. Unmount the device.
289 4. Run mtp-detect. It will most likely fail the first time.
290 5. Run mtp-detect again, it might work this time, or fail. Keep running
291    till it works. 99% it works by the third try.
292 6. Once mtp-detect gives you an "Ok", open either Rhythmbox or Gnomad2,
293    everything should work.
295Linux: Try this, if you have a recent 2.6.x Linux kernel,
296run (as root) something like:
298> rmmod usb_storage ; mtp-detect
300You can run most any command or a client like gnomad2 or
301Amarok immediately after the rmmod command. This works 
302sometimes. Another way:
304* Edit /etc/modprobe.d/blacklist
306* Add the line "blacklist usb-storage"
308* Reboot.
310Now none of you USB disks, flash memory sticks etc will be 
311working (you just disabled them all). However you *can* try
312your device, and it might have started working because there
313is no longer a USB mass storage driver that tries to hook onto
314the mass storage interface of your device.
316If not even blacklisting works (check with 
317"lsmod | grep usb-storage"), there is some problem with
318something else and you may need to remove or rename the file 
322If you find the PerfectSolution(TM) to this dilemma, so you 
323can properly switch for individual devices whether to use it
324as USB mass storage or not, please tell us how you did it. We
325know we cannot use udev, because udev is called after-the-fact:
326the device is already configured for USB mass storage when
327udev is called.
329On Mac OS there is another ugly hack:
3311. Open up a terminal window
3322. Type:
333sudo mv /System/Library/Extensions/IOUSBMassStorageClass.kext
336and when prompted enter your password.
3383. Restart.
340To reverse this change, just reverse the filenames:
342sudo mv /System/Library/Extensions/
343IOUSBMassStorageClass.kext.disabled /System/Library/Extensions/
346and restart.
349Calendar and contact support:
352The Creative Zen series can read VCALENDAR2 (.ics) files
353and VCard (.vcf) files from programs like for example
354Evolution with the following limitations/conditions: 
356- The file must be in DOS (CR/LF) format, use the unix2dos
357  program to convert if needed
359- Repeat events in calendar files do not seem to be supported, 
360  entries will only appear once.
362- Calendar (.ics) files should be stored in the folder "My Organizer" 
363  when sent to the device (this directory should be autodetected
364  for use with calendar files, otherwise use the option 
365  -f "My Organizer" to sendfile for this) Apparently this file can
366  also contain tasklists.
368- Contact (.vcf) files should be stored in the folder "My Contacts"
369  when sent to the device. (-f "My Contacts")
371- Some devices are picky about the name of the calendar and
372  contact files. For example the Zen Microphoto wants:
374  Calendar: My Organizer/6651416.ics
375  Contacts: My Organizer/6651416.vcf
378Syncing in with Evolution and Creative Devices
381Evolution can easily export .ics an .vcf files, but you currently
382need some command-line hacking to get you stuff copied over in
383one direction host -> device. The examples/ directory contains a script
384created for the Creative Zen Microphoto by Nicolas Tetreault.
387It's Not Our Bug!
390Some MTP devices have strange pecularities. We try to work around
391these whenever we can, sometimes we cannot work around it or we 
392cannot test your solution.
394* Generic MTP/PTP disconnect misbehaviour: we have noticed that 
395  Windows Media Player apparently never close the session to an MTP
396  device. There is a daemon in Windows that "hooks" the device
397  by opening a PTP session to any MTP device, whenever it is 
398  plugged in. This daemon proxies any subsequent transactions 
399  to/from the device and will never close the session, thus
400  Windows simply does not close sessions at all.
402  Typical sign of this illness: broken pipes on closing sessions,
403  on the main transfer pipes(s) or the interrupt pipe:
405    Closing session
406    usb_clear_halt() on INTERRUPT endpoint: Broken pipe
407    OK.
409  This means that device manufacturers doesn't notice any problems
410  with devices that do not correctly handle closing PTP/MTP
411  sessions, since Windows never do it. The proper way of closing
412  a session in Windows is to unplug the device, simply put.
414  Since libmtp actually tries to close sessions, some devices
415  may fail since the close session functionality has never been
416  properly tested, and "it works with Windows" is sort of the
417  testing criteria at some companies.
419  You can get Windows-like behaviour on Linux by running a HAL-aware
420  libmtp GUI client like Rhythmbox or Gnomad2, which will "hook"
421  the device when you plug it in, and "release" it if you unplug
422  it.
424  If this bug in your device annoys you, contact your device 
425  manufacturer and ask them to test their product with some libmtp 
426  program.
428* Generic USB misbehaviour: some devices behave badly under MTP
429  and USB mass storage alike, even down to the lowest layers
430  of USB. You can always discuss such issues at the linux-usb
431  mailing list if you're using Linux: 
434  If you have a problem specific to USB mass storage mode, there
435  is a list of strange behaving devices in the Linux kernel:
437  You can discuss this too on the mentioned list, for understanding
438  the quirks, see:
441* Kernel bug on Linux. Linux 2.6.16 is generally speaking required
442  to use any MTP device under USB 2.0. This is because the EHCI
443  driver previously did not support zero-length writes to endpoints.
444  It should work in most cases however, or if you connect it
445  to an UHCI/OHCI port instead (yielding lower speed). But 
446  please just use a recent kernel.
448* Zen models AVI file seeking problem: the Zens cannot parse the
449  files for the runlength metadata. Do not transfer file with e.g.
450  mtp-sendfile, use mtp-sendtr and set the length of the track to
451  the apropriate number of seconds and it will work. In graphical
452  clients, use a "track transfer" function to send these AVI files,
453  the Zens need the metadata associated with tracks to play back
454  movies properly. Movies are considered "tracks" in the MTP world.
456* Some devices that disregard the metadata sent with the MTP 
457  commands will parse the files for e.g. ID3 metadata. Some still
458  of these devices expect only ID3v2.3 metadata and will fail with
459  a modern ID3v2,4 tag writer, like many of those found in Linux
460  applications. Windows Media Player use ID3v2.3 only, so many
461  manufacturers only test this version.
463* The Zen Vision:M (possibly more Creative Zens) has a firmware bug
464  that makes it drop the last two characters off a playlist name.
465  It is fixed in later firmware.
467* For Creative Technology devices, there are hard limits on how
468  many files can be put onto the device. For a 30 GiB device (like
469  the Zen Xtra) the limit is 6000, for a 60 GiB device the limit
470  is 15000 files. For further Creative pecularities, see the
471  FAQ sections at
473* Sandisk sansa c150 and probably several other Sandisk devices 
474  (and possibly devices from other manufacturers) have a dual
475  mode with MTP and USB mass storage. The device will initially
476  claim to be mass storage so udev will capture is and make the
477  use of MTP mode impossible. One way of avoiding it could be to
478  be to blacklist the "usb-storage" module in 
479  /etc/modprobe.c/blacklist with a row like this:
480  "blacklist usb-storage". Some have even removed the
481  "usb-storage.ko" (kernel module file) to avoid loading.
483* Sandisk Sansa Fuze has three modes: auto, MTP or mass storage
484  (MSC). Please set it to MTP to avoid problems with libmtp.
486* The iriver devices (possibly all of them) cannot handle the 
487  enhanced GetObjectPropList MTP command (0x9805) properly. So 
488  they have been banned from using it.
490* iriver devices have problems with older versions of libmtp and
491  with new devices libmtp does not know of as of yet, since it
492  has an oldstyle USB device controller that cannot handle zero
493  writes. (Register your device with us!) All their devices are
494  likely to need a special device flag in the src/libusb-glue.c
495  database.
497* The Samsung Yepp T9 has several strange characteristics, some
498  that we've managed to work around. (For example it will return
499  multiple PTP packages in a single transaction.)
501* The early firmware for Philips HDD players is known to be 
502  problematic. Please upgrade to as new firmware as you can get.
503  (Yes this requires some kind of Windows Installation I think.)
505* Philips HDD 1630/16 or 1630/17 etc may lock themselves up,
506  turning inresponsive due to internal corruption. This typically
507  gives an error in opening the PTP session. Apparently you can
508  do a "repair" with the firmware utility (Windows only) which
509  will often fix this problem and make the device responsive
510  again.
512* Some devices that implement GetObjectPropList (0x9805) will
513  not return the entire object list if you request a list for object
514  0xffffffffu. (But they should.) So they may need the special
517* Some (smaller) subset of devices cannot even get all the 
518  properties for a single object in one go, these need the
520  iriver devices seem to have this bug.
522* The Toshiba Gigabeat S (and probably its sibling the 
523  Microsoft Zune and other Toshiba devices) will only display
524  album information tags for a song in case there is also
525  an abstract album (created with the album interface) with
526  the exact same name.
528* The Zen Vision:M has an older firmware which is very corrupt,
529  it is incompatible with the Linux USB stack altogether. The
530  kernel dmesg will look something like this, and you have to
531  upgrade the firmware using Windows:
532  usb 4-5: new high speed USB device using ehci_hcd and address 5
533  usb 4-5: configuration #1 chosen from 1 choice
534  usb 4-5: can't set config #1, error -110
536* The Sirus Stiletto does not seem to allow you to copy any files
537  off the device. This may be someone's idea of copy protection.
539* The Samsung P2 assigns parent folder ID 0 to all unknown file
540  types.(i.e. moves them to the root folder) 
542Lost symbols
545Shared libraries can be troublesome to users not experienced with
546them. The following is a condensed version of a generic question 
547that has appeared on the libmtp mailing list from time to time.
549> PTP: Opening session
550> Queried Creative Zen Vision:M
551> gnomad2: relocation error: gnomad2: undefined symbol:
552> LIBMTP_Get_Storageinfo
553> (...)
554> Are these type of errors related to libmtp or something else?
556The problem is of a generic nature, and related to dynamic library 
557loading. It is colloquially known as "dependency hell".
560The gnomad2 application calls upon the dynamic linker in Linux to
561resolve the symbol "LIBMTP_Get_Storageinfo" or any other symbol
562(ELF symbol, or link point or whatever you want to call them, a
563symbol is a label on a memory address that the linker shall 
564resolve from label to actual address.)
565For generic information on this subject see the INSTALL file and
566this Wikipedia page:
570When Linux /lib/ is called to link the symbols compiled 
571into gnomad2 (or any other executable using libmtp), it examines the 
572ELF file for the file it finds first and cannot resolve 
573the symbol "LIBMTP_Get_Storageinfo" (or whichever symbol you have a
574problem witj) from it, since it's probably not there. There are many 
575possible causes of this symbol breakage:
5771) You installed precompiled libmtp and gnomad2 packages (RPMs, debs
578    whatever) that do not match up. Typical cause: your gnomad2 package was
579    built against a newer version of libmtp than what's installed on your
580    machine. Another typical cause: you installed a package you found on
581    the web, somewhere, the dependency resolution system did not protest
582    properly (as it should) or you forced it to install anyway, ignoring
583    some warnings.
5852) You compiled libmtp and/or gnomad2 from source, installing both or
586    either in /usr/local/lib and /usr/local/bin. This means at compile-time
587    gnomad2 finds the libmtp library in /usr/local/lib but at runtime, it
588    depends on the Linux system wide library loader (/lib/ in
589    order to resolve the symbols. This loader will look into the file
590    /etc/ and/or the folder /etc/ in order to find
591    paths to libraries to be used for resolving the symbols. If you have
592    some older version of libmtp in e.g. /usr/lib (typically installed by a
593    package manager) it will take precedence over the new version you just
594    installed in /usr/local/lib and the newly compiled library in
595    /usr/local/lib will *not* be used, resulting in this error message.
5973) You really did install the very latest versions (as of writing libmtp
598    0.1.5 and gnomad2 2.8.11) from source and there really is no
599    pre-installed package of either on your machine. In that case I'm
600    totally lost, I have no idea what's causing this.
602Typical remedies:
6041) If you don't want to mess around with your system and risk these
605    situations, only use pre-packaged software that came with the
606    distribution or its official support channels. If it still breaks,
607    blame your distribution, they're not packaging correctly. Relying on
608    properly packaged software and not installing things yourself *is* the
609    Linux solution to the "dependency hell" problem.
6112) Read about dynamically linked library handling until the stuff I wrote
612    about in the previous list sounds like music to your ears, inspect
613    your /lib, /usr/lib, /usr/local/lib, /etc/ and the
614    /etc/, remove all pre-packed versions using RPM, APT,
615    YaST or whatever your distribution uses, compile libmtp and gnomad2
616    (or whatever) from source only and you will be enlighted.
618I don't know if this helps you, it's the best answer we can give.
621API is obscure - I want plain files!
624PTP/MTP devices does not actually contain "files", they contain
625objects. These objects have file names, but that is actually
626just a name tag on the object.
628Folders/directories aren't really such entities: they are just 
629objects too, albeit objects that can act as parent to other
630objects. They are called "associations" and are created in atomic
631fashion and even though there is an MTP command to get all the
632associations of a certain association, this command is optional
633so it is perfectly possible (and most common, actually) to create
634devices where the "folders" (which are actually associations) have
635no idea whatsoever of what files they are associated as parents to 
636(i.e. which files they contain). This is very easy for device
637manufacturers to implement, all the association (i.e. finding out
638which files are in a certain folder) has to be done by the MTP
639Initiator / host computer.
641Moving a file to a new folder is for example very simple in a
642"real" file system. In PTP/MTP devices it is often not even possible,
643some devices *may* be able to do that. But actually the only
644reliable way of doing that is to upload the file to the host,
645download it with the new parent, then delete the old file.
646We have played with the idea of implementing this time consuming
647function, perhaps we will.
649Then the issue that in PTP/MTP it is legal for two files to have
650exactly the same path as long as their object IDs differ. A
651folder/association can contain two files with the exact same name.
652(And on the Creative devices this even works, too, though most devices
653implicitly fail at this.) Perhaps one could add some custom hook for
654handling that, so they become  /Foo.mp3 and /Foo.mp3(1) or something
655similar, but it's really a bit kludgy.
657Playlists and albums aren't really files, thinking about 
658them as files like the hacks in libgphoto2 is really backwards. They are
659called associations and are more like a symbolic link that links in a
660star-shaped pattern to all the files that are part of the album/playlist.
661Some devices (Samsung) thought that was too complicated and have a
662different way of storing playlists in an UTF-16 encoded .spl-like file
663instead! This is why playlists/albums must have their own structs and 
666Plain file access also assumes to be able to write files of an
667undetermined size, which is simply not possible in a transactional
668file system like PTP/MTP. (See further below.)
671I Want Streaming!
674Streaming reads is easy. Just connect the output file descriptor from
675LIBMTP_Get_File_To_File_Descriptor() (and a similar function for tracks)
676wherever you want.
678People have connected this to TCP sockets for streaming web servers 
679etc, works like a charm. Some devices will even survive if the callback 
680functions return non-zero and cancel the download. Some devices will
681lock up and even require a reset if you do that. Devices are poorly
682implemented so that's life. If you want to stream off a device, the
683best idea is always to stream the entire file and discard the stuff
684at the end you don't want. It will incur a delay if you e.g. want to
685skip between tracks, sadly.
687Then we get to the complicated things: streaming WRITES...
689There is a function:
690LIBMTP_Send_File_From_File_Descriptor() (and similar for tracks)
691which will write a file to a device from a file descriptor, which may
692be a socket or whatever.
694HOWEVER: this requires a piece of metadata with the .filesize properly
695set first.
697This is not because we think it is funny to require that, the protocol
698requires it. The reason is that PTP/MTP is a transactional file system
699and it wants to be able to deny file transfer if the file won't fit on
700the device, so the transaction never even starts, it's impossible to
701start a transaction without giving file length.
703People really want streaming so I tried a lot of hacks to see if they
704would work, such as setting file size to 0xffffffffU or something other
705unnaturally big and then aborting the file transfer when the stream ends.
706It doesn't work: either the device crashes or the file simply disappears
707since the device rolls back all failed transactions.
709So this is an inherent limitation of the PTP/MTP protocol.

1This file was created by James Ravenscroft <> as a direct revision of Farooq Zaman's work with LibMTP on Windows.
514th January 2009: Created the first revision of this file taking information from the work of Farooq Zaman.
7 1.0 Compilation of LibMTP on Windows 2000/XP/NT 
9LibMTP currently compiles under Windows using MingW/MSys. The source relies upon the __WIN32__ macro which is defined by MinGW by default.
12LibMTP currently depends on LibUSB and libiconv. There are currently projects that port both of these libraries to Windows. Binary files can be
13obtained from:
15LibUSB Win32 -
17LibIconv -
19With both of these libraries extracted and placed in MinGW's search path, you can compile the library by opening the Msys prompt, navigating to
20the path where the extracted LibMTP source files can be found and typing:
23make all
24make install
28 2.0 LibUSB and Driver Issues for Windows
31Unfortunately, Windows does not have abstract USB support and depends upon specific drivers for each and every device you use. Fortunately, 
32LibUSB-Win32 provide a solution to this problem. LibMTP takes advantage of the LibUSB-Win32 Device Driver package.
341. Download the latest device driver binary package (libusb-win32-device-bin-x.x.x.x.tar.gz) from
352. Upon extraction, plug in your music device and run bin/inf-wizard.exe. Selecting your device and saving the inf file in the project root directory.
363. Copy the files "bin/libusb0.dll" and "libusb0.sys" or "libusb0_x64.dll" and "libusb0_x64.sys" for 32-bit or 64-bit operating systems respectively.
374. Goto Start -> Run, type "devmgmt.msc" and press "ok".
385. Select your music device from the list and click Action -> Update Driver, Choose "No, not this time" if prompted to connect to microsoft.
396. Choose "Install from a list or specific location".
407.  Choose "Don't search, I will choose the driver to install
418. Click the "Have Disk..." button in the bottom right corner of the prompt
429. Browse to your .inf file and select it. Press Ok 
4310. The name of your music device should appear in the prompt, click it and click "Next>" (Ignore any prompts about Driver Signing, continuing 
44installation of the selected driver).
4511. Click finish to end the driver install process.
47To get your old driver back:
491. Goto Start -> Run, type "devmgmt.msc" and press "ok".
502. Select your music device, right click on it and click "Properties"
513. Go to the "Driver" pane and select "Roll Back Driver".
53 3.0