T10 MTP...for Linux ?

[nibbler]

Originally Posted by orthoB

You should eMail the gphoto2 folks (gphoto.sourceforge. net) so your ID's get into the 2.2 baseline.

I've now done this. There would seem to be two IDs for each T10, T20 and T30. Wonder why that is? UMS vs MTP or different regions?

Originally Posted by orthoB

What I posted previously is about as far as I want to take it for now. Basically we figured out the playlist format and wrote a python script to create one from a file-list. The next step is for someone (you?) to integrate this proof-of-concept in with a file manager. To be usefull, it requires some directory structure that corresponds to one on the iRiver device. Once there's a filelist, it's just a formatting job to create the playlist file.

Not sure whether it's me or my PC but I tried to look at your pla.zip file attached to an earlier post but I cannot open the file for some reason. If I can get this file open then I don't mind having a close look at putting it to good practical use.

Originally Posted by orthoB

Glad it helped you out! As SonuvBob points out, xfer's are slow since gphoto2 starts a new session (and grabs the entire directory) for each file that's transfered. Quite a lot of overhead. The raw data xfer is probably at full usb2 rates.

Anyone want to hack gphoto2 to do multiple file transfers? There should be a big payoff in transfer rates.

From the quick look I had of the source for gphoto2, it's nicely formatted and is just asking for modification. I'd do it myself if my C skills were up to the task. It needs an 'upload all files' option just like there is a 'get all files' option. I've just noticed someone has just posed this question on the gphoto-devel mail list,
http://sourceforge.net/mailarchive/f...forum_id=32960
Think I'll keep an eye on the response.

BTW, for those not aware, if running KDE then you can use Konqueror file manager to drag files from your T device as long as it's auto detected ok. Just stick 'camera:/' into the location box to get going. Can't upload though as it's geared towards cameras.

[orthoB]

Originally Posted by SonuvBob

MTP spec can be found at http://www.microsoft.com/downloads/d...displaylang=en
I'm not sure if it requires Windows/IE to d/l, but it can be extracted w/winrar and read with OpenOffice Writer. Quite a lot of legalese attached to it; all I can make out is that I'm not allowed to post the file here.

Downloaded on Linux w/ Firefox, and used "cabextract" from the Fedora-extras repository to extract the .doc. Used OpenOffice (as you did) and then wrote it as .pdf. Got a real nice pdf with the TOC links in the sidebar.

Actually the legalize seems pretty light. The front page caveats basically say that this is a draft - so don't assume it's correct and bank your company on it (MS reserves the right to laugh at you). The only other legal statement seems to be the footer on every page:

For Review and Discussion Only
Draft Document Subject to Revision or Rejection
Not For Publication or General Distribution

The last line seems debatable, since MS is publishing it on a fully open webpage (seems like general distribution to me). Despite the cautions in Introduction to MTP: Media Transfer Protocol (http://www.analogzone.com/iot_0328.pdf) about this spec (or a similar one?), this version of the doc seems pretty clean. No EULA-like front matter that identifies this as MS intellectual property; There's just a distribution restriction in the footer. The Intro paper pdf was created Mar'2005, while this version of the MS doc postdates it (Aug'2005) - looks like MS lightened up on the legalease.

In fact, all the verbage in the document seems consistent with this being an open document. Especially section 1.2 (quoted for purpose of discussion):

1.2 Scope This specification is intended to define the transport-independent portion of MTP in a way that is agnostic to both device type and OS. Additional specification on how this protocol is defined over a particular transport is required to fully implement this protocol, and will be provided either in an appendix or in a separate document. Certain operating systems or device classes may require a particular subset of MTP to enable their minimal scenarios; it is strongly suggested that implementers investigate the intended usage scenarios to determine if any such requirements exist.

The "agnostic to ... OS" seems like a real nice statement for Linux developers. Especially from MS.

Anyone find any specific nastiness in the doc? So far, it looks like folks can download it from the site and discuss it openly.

[SonuvBob]

This is what you get when you run the .exe:

Originally Posted by Microsoft

END USER LICENSE AGREEMENT FOR
Microsoft Media Transfer Protocol
Specification v0.83

These license terms are an agreement between Microsoft Corporation (or based on where you live, one of its affiliates) and you. Please read them. They apply to the Microsoft specification that you are about to download, which includes the media on which you received it, if any (“Specification”). The terms also apply to any Microsoft
* updates/upgrades,
* supplements,
* Internet-based services, and
* support services
* documentation
for this Specification, unless other terms accompany those items. If so, those terms apply.
By using this Specification, you accept these terms. If you do not accept them, do not use the Specification.


SPECIFICATION LICENSE

The Specification is protected by copyright and other intellectual property laws and treaties. Microsoft or its suppliers own the title, copyright, and other intellectual property rights in the Specification. Microsoft reserves all rights not expressly granted to you in this agreement. The Specification is licensed, not sold.


1. GRANT OF LICENSE. This section of the agreement describes your general rights to install and use the Specification. The license rights described in this section are subject to all other terms and conditions of this agreement. You may:

* install and use up to 20 copies of the Specification to design, develop, and test your application or product that utilizes the Specification (your "Licensed Implementation") and;
* make a reasonable number of copies of the Specification for backup and archival purposes.


2. LICENSE LIMITATIONS

(a) This license does not include the right to build a Licensed Implementation for a personal computer that implements that “Enhanced Initiator” features, as described in the Specification. To build such an implementation, you must obtain a separate license from Microsoft. Please contact WMLA@Microsoft.com to request this license.

(b) This license does not include the right to distribute your Licensed Implementation. In order to distribute your Licensed Implementation, you must download the Microsoft Windows Media Transport Porting Kit and accept its license terms.
(c) You must not
* alter any copyright, trademark or patent notice in the Specification;
* use Microsoft’s trademarks in your Licensed Implementation’s name or in a way that suggests your Licensed Implementation come from or are endorsed by Microsoft;
* include the Specification in malicious, deceptive or unlawful programs; or

(d) You may not alter any component of the Specification.

(e) Subject to the limitation in Section 2 (a), Your Licensed Implementation must implement the Specification in its entirety. However, you are not required to implement any portion of the Specification that is identified as “optional”. If you choose to implement a portion of the Specification that is identified as optional, you must implement that portion in its entirety.

3. DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS:

(a) Trademarks. This agreement does not grant you any rights in connection with any trademarks or service marks of Microsoft. For more information about Microsoft logo license agreements, send an e-mail to wmla@microsoft.com.

(b) Termination. Without prejudice to any other rights, Microsoft may terminate this agreement if you fail to comply with the terms and conditions of this agreement. In such event, you must destroy all copies of the Specification.

(c) Support Services. Because this Specification is “as is,” Microsoft may not provide support services for it.

(d) Technical Support for Your Licensed Implementation. You are responsible for any and all maintenance, end-user support, technical support and updates for your Licensed Implementation.

4. SCOPE OF LICENSE. The Specification is licensed, not sold. This agreement only gives you some rights to use the Specification. Microsoft reserves all other rights. Unless applicable law gives you more rights despite this limitation, you may use the Specification only as expressly permitted in this agreement. In doing so, you must comply with any technical limitations in the Specification that only allow you to use it in certain ways. You may not
* make more copies of the Specification than specified in this agreement or allowed by applicable law, despite this limitation;
* publish the Specification for others to copy;
* rent, lease or lend the Specification;
* transfer the Specification or this agreement to any third party;
* or use the Specification for commercial software hosting services.

5. CONFIDENTIALITY. The Specification may contain specifications or documents which are proprietary and confidential information to Microsoft and its suppliers. Except as provided in Section 1 and below in this Section 5, you agree not to disclose or provide such specifications, documentation, or related information to any third party. However, However, (i) you may provide this information to your employees and contractors who have executed written confidentiality agreements that oblige them to comply with confidentiality terms equivalent to the requirements of this agreement; (ii) you may distribute Documents in their entirety as part of your Licensed Implementation; and (iii)You may disclose confidential information in accordance with judicial or other governmental order, provided recipient shall give Microsoft reasonable written notice prior to such disclosure and shall comply with any applicable protective order or equivalent. Further, you shall not be liable to Microsoft for disclosure of information which you can prove (a) is already known to you without an obligation to maintain the same as confidential; (b) becomes publicly known through no wrongful act of recipient; (c) is rightfully received from a third party without breach of an obligation of confidentiality owed to Microsoft; or (d) is independently developed by you.

6. DISCLAIMER OF WARRANTIES. The Specification is licensed “as-is.” You bear the risk of using it. Microsoft gives no express warranties, guarantees or conditions. You may have additional consumer rights under your local laws which this agreement cannot change. To the extent permitted under your local laws, Microsoft excludes the implied warranties of merchantability, fitness for a particular purpose and non-infringement.

7. LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. You can recover from Microsoft and its suppliers only direct damages up to U.S. $5.00. You cannot recover any other damages, including consequential, lost profits, special, indirect or incidental damages. This limitation applies to
* anything related to the Specification, services, content (including code) on third party Internet sites, or third party programs; and
* claims for breach of contract, breach of warranty, guarantee or condition, strict liability, negligence, or other tort to the extent permitted by applicable law.
It also applies even if Microsoft knew or should have known about the possibility of the damages. The above limitation or exclusion may not apply to you because your country may not allow the exclusion or limitation of incidental, consequential or other damages.

8. EXPORT RESTRICTIONS. The Specification is subject to United States export laws and regulations. You must comply with all domestic and international export laws and regulations that apply to the Specification. These laws include restrictions on destinations, end users and end use. For additional information, see www.microsoft.com/exporting.

9. APPLICABLE LAW. Washington state law governs the interpretation of this agreement and applies to claims for breach of it, regardless of conflict of laws principles.
10. LEGAL EFFECT. This agreement describes certain legal rights. You may have other rights under the laws of your country. You may also have rights with respect to the party from whom you acquired the Specification. This agreement does not change your rights under the laws of your country if the laws of your country do not permit it to do so.

11. ENTIRE AGREEMENT. This agreement, and the terms for supplements, updates, Internet-based services and support services that you use, are the entire agreement for the Specification and support services.

Should you have any questions concerning this agreement, or if you desire to contact Microsoft for any reason, please contact the Microsoft subsidiary serving your country, or write: Microsoft, One Microsoft Way/Redmond, WA 98052-6399.

Hopefully I can at least post the EULA legally

[SonuvBob]

Originally Posted by nibbler

I've now done this. There would seem to be two IDs for each T10, T20 and T30. Wonder why that is? UMS vs MTP or different regions?

I think each of the three players has both a 512MB and a 1GB version also. Maybe this is the basis? I have the 1GB (MTP, US) T10, and it has the 'iRiver T10 (alternate)' id.

Originally Posted by nibbler

I've just noticed someone has just posed this question on the gphoto-devel mail list,
http://sourceforge.net/mailarchive/f...forum_id=32960
Think I'll keep an eye on the response.

The response:

You could put multiple -u filename on one commandline.

But yes, upload is an undervalued and undertested functionality up
to the event of MTP players.

I will see what I can do

Ciao, Marcus

Oops, didn't try that

[twillster]

I did try both using just folders to upload as well as filenames. Neither seemed to work...

Then again, I did try with the py script but not straight with the command line. The command line itself might work I guess. Didn't think about it.

I know that the script doens't handle any wildcards (which is obvious if you've looked at it as to why it doesn't.. it wasn't made to!)

Anyhow, i'll try that maybe tonight or tomorrow. I'm hoping to actually get to dig into gphoto2 code tonight. I got to play around a little yesterday and was looking at the functions for get_all_files and it appears to be a pretty simple fix. I need to dust off my C a bit though.

Maybe be able to get that perl written too. :S

too much to do and too little time.

[msfroh]

I've written a shell script to upload an entire directory tree (using multiple "-u" and "-m" flags on the command line). Since it looks like you can only have one active "-f" parameter, it must run gphoto2 from each directory with files to upload. It seems to handle file names with spaces reasonably well.

upload_tree.sh

Suppose in the current directory, you've got a directory called "mydir". Just run "upload.sh mydir" to upload the whole thing. It will be rooted at /store_00010001/ by default, but with an optional second parameter, you can specify a different root.

Incidentally, I suspect that multi-file upload may be a little harder to implement in gphoto2 itself than multi-file download. In particular, libgphoto2 looks to me like its got more directory-browsing functions at the camera end than it does the local filesystem end. I dug around for a while last night, and ended up giving up without writing anything. I hope others have better luck.

[twillster]

Originally Posted by msfroh

Incidentally, I suspect that multi-file upload may be a little harder to implement in gphoto2 itself than multi-file download. In particular, libgphoto2 looks to me like its got more directory-browsing functions at the camera end than it does the local filesystem end. I dug around for a while last night, and ended up giving up without writing anything. I hope others have better luck.

Don't you suppose though that if you just provide the multi-file upload similar to their multi-download it shouldn't be that bad. I haven't dug into libgphoto2 yet but doesn't the get_all_files function simply pulls all files from a single directory. I don't know that it traverses all other directories within itself...

[orthoB]

Yech! Really evil stuff. Since it requires a windoze box to run the exe, I never saw it (don't have any windoze boxen). So maybe it only applies to windoze users ... (wishful thinking - lawyers & sharks aren't that discriminating). Usually docs like that will have the legal section integrated into the document, or at least bundled with the doc. If the exe contained a Eula.doc as well as the MTP doc it would have been a clear warning. So ... open website, nice doc with an inviting section 1.2, and a hidden Eula!

Thanks for the post - saved me from possibly doing something stupid with possibly painfull consequences.

Shucks, time to burn the bits

[msfroh]

Originally Posted by twillster

Don't you suppose though that if you just provide the multi-file upload similar to their multi-download it shouldn't be that bad. I haven't dug into libgphoto2 yet but doesn't the get_all_files function simply pulls all files from a single directory. I don't know that it traverses all other directories within itself...

As I understand the code, get_all_files calls for_each_file (passing the current camera context, including target folder on the camera), with a pointer to the save_file_to_file function. The thing that scared me off was the fact that for_each_file gets the list of available files using gp_camera_folder_lis t_files, which uses the current camera context. There doesn't seem to be an equivalent list_files function for use on the local filesystem (though I suppose one could implement one). Also, the save_file_to_file function would need to be reimplemented, I think (as it uses gp_camera_save_file_ to_file, which seems to be only a downloading function).

Again, it looks like it's a lot easier to download with gphoto than it is to upload.

Of course, I'm not absolutely positive about any of this. It may be a lot easier than I'm making it out to be.

[SonuvBob]

Originally Posted by msfroh

As I understand the code, get_all_files calls for_each_file (passing the current camera context, including target folder on the camera), with a pointer to the save_file_to_file function. The thing that scared me off was the fact that for_each_file gets the list of available files using gp_camera_folder_lis t_files, which uses the current camera context. There doesn't seem to be an equivalent list_files function for use on the local filesystem (though I suppose one could implement one). Also, the save_file_to_file function would need to be reimplemented, I think (as it uses gp_camera_save_file_ to_file, which seems to be only a downloading function).

Again, it looks like it's a lot easier to download with gphoto than it is to upload.

Of course, I'm not absolutely positive about any of this. It may be a lot easier than I'm making it out to be.

Yeah, that's the impression I got too. The hardest part would be implementing the list_files function, assuming you just wanted it to be able to upload a directory at a time. Allowing wildcards might be a pain too- glob.h looks pretty useful though. Honestly I have no idea how difficult the filesystem bit is in C: I tend to flee to Perl/Bash for that kind of thing. Marcus M. from the gphoto-devel mailing list said he'd look into it, so those two combined are my excuse for not doing it myself

I also think it'd be pretty cool to make a Python wrapper for libgphoto2. Probably a lot of work involved, but I imagine a lot of people would find it useful.

Yech! Really evil stuff. Since it requires a windoze box to run the exe, I never saw it (don't have any windoze boxen). So maybe it only applies to windoze users ... (wishful thinking - lawyers & sharks aren't that discriminating). Usually docs like that will have the legal section integrated into the document, or at least bundled with the doc. If the exe contained a Eula.doc as well as the MTP doc it would have been a clear warning. So ... open website, nice doc with an inviting section 1.2, and a hidden Eula!

Thanks for the post - saved me from possibly doing something stupid with possibly painfull consequences.

Shucks, time to burn the bits

No problem. I was surprised that the EULA isn't a separate file. Maybe Microsoft thought non-Windows users couldn't download the file anyway? (Did you notice the JavaScript for the download button that checks if you're using IE? Ugh.) Then again, WinRAR can extract it, skipping the EULA as well...

I don't speak Legalese too well: does the EULA prevent an LGPL'd open source
implementation of the MTP protocol (or at least using their .doc to do it)? I'm not sure what the “Enhanced Initiator” features are- is this just the MTP extensions to PTP, or certain ones in particular? Also looks like there's another EULA you have to agree to if you want to distribute your implementation. Fun fun fun.

[twillster]

Originally Posted by msfroh

As I understand the code, get_all_files calls for_each_file (passing the current camera context, including target folder on the camera), with a pointer to the save_file_to_file function. The thing that scared me off was the fact that for_each_file gets the list of available files using gp_camera_folder_lis t_files, which uses the current camera context. There doesn't seem to be an equivalent list_files function for use on the local filesystem (though I suppose one could implement one). Also, the save_file_to_file function would need to be reimplemented, I think (as it uses gp_camera_save_file_ to_file, which seems to be only a downloading function).

Again, it looks like it's a lot easier to download with gphoto than it is to upload.

Of course, I'm not absolutely positive about any of this. It may be a lot easier than I'm making it out to be.

Well you dug in deeper than I did. that could get scary.

edit: I'm going to quit promising that I'm gonna look at it until I actually do.

[nibbler]

Anyone else got any updates on anything they are writing?

Time for an update from me.

I've updated my sync script now and it can be found at:
http://www.nibbler.dsl.pipex.com/tsync
Yup, it's a frightening script, but it works for me!

It now supports uploading whole folders and individual files. It will delete whole folders and individual files. Basically, it will sync whatever is in the assigned sync directory on your hdd.
Also, it will download contents of VOICE and RECORD folders and delete their contents. It will ask first for confirmation though.

I'm going to have a go at incorporating playlists now.

Let me know how it works out - comments welcome.
In the meantime, enjoy.

[ckaga2000]

I've Just purchased a T10 iGB iRiver. And after following all the instructions on this thread and on the gphoto2 FAQ I've got everything almost working.

The problem I'm running into I've yet to find anything on. Essentially whenever I try to transfer more than 512M to the T10 it stops responding.

*** Error ***
PTP Protocol error, response expected

*** Error ***
PTP Protocol error, data expected
*** Error (-1: 'Unspecified error') ***


from then on I cannot upload anymore using gphoto2. Trying "ghpoto2 -l" yeilds:
*** Error ***
PTP Protocol error, response expected
There is one folder in folder '/':
- store_00010001
There are no folders in folder '/store_00010001'.

Even though the iRiver browser clearly shows everything I've uploaded until then. Reconnecting the T10 does nothing, the only way to get it to communicate with gphoto2 again is to delete files. At this point I might as well have bought a 512MB player.

I'm running Fedora Core 4 with kernel 2.6.14-1.1637_FC4smp I've installed gphoto2-2.1.99-3.

FWIW: Running detail debug on a sucessful transfer, and the same transfer when it fails only reveals the following difference:
0.142108 ptp(2): PTP: Opening session
0.142143 gphoto2-port(2): Writing 16=0x10 byte(s) to port...
0.142169 gphoto2-port(3): Hexdump of 16 = 0x10 bytes follows:
0000 10 00 00 00 01 00 02 10-00 00 00 00 01 00 00 00 ................

0.142279 gphoto2-port(2): Reading 512=0x200 bytes from port...
0.142385 gphoto2-port(2): Could only read 12 out of 512 byte(s)
0.142434 gphoto2-port(3): Hexdump of 12 = 0xc bytes follows:
0000 0c 00 00 00 03 00 01 20-04 00 00 00 ....... ....

0.142482 gphoto2-port(2): Writing 12=0xc byte(s) to port...
0.142525 gphoto2-port(3): Hexdump of 12 = 0xc bytes follows:
0000 0c 00 00 00 01 00 01 10-01 00 00 00 ............

0.142633 gphoto2-port(2): Reading 512=0x200 bytes from port...
0.144133 gphoto2-port(2): Could only read 12 out of 512 byte(s)
0.144156 gphoto2-port(3): Hexdump of 12 = 0xc bytes follows:
0000 0c 00 00 00 03 00 04 20-01 00 00 00 ....... ....

0.144198 context(0): PTP Protocol error, data expected

*** Error ***
PTP Protocol error, data expected
0.144252 gphoto2-port(2): Closing port...
0.146687 context(0): An error occurred in the io-library ('Unspecified error'): Could not query kernel driver of device.

*** Error ***
An error occurred in the io-library ('Unspecified error'): Could not query kernel driver of device.
*** Error (-1: 'Unspecified error') ***

0.147489 gp-camera(2): Freeing camera...
0.147513 gphoto2-port(2): Freeing port...
0.147533 gphoto2-port(2): Closing port...
0.147604 libgphoto2/gphoto2-filesys.c(2): Clearing fscache LRU list...
0.147624 libgphoto2/gphoto2-filesys.c(2): fscache LRU list already empty
0.147644 gphoto2-filesystem(2): Internally deleting all folders from '/'...

[SonuvBob]

Originally Posted by ckaga2000

Reconnecting the T10 does nothing, the only way to get it to communicate with gphoto2 again is to delete files.

The same thing happened with the problem we ran into when the T10 had a certain numbers of files and folders on it. Couldn't use it again with gphoto2 until a file was deleted (or added). Are you sure it's an issue with the size?

Originally Posted by ckaga2000

FWIW: Running detail debug on a sucessful transfer, and the same transfer when it fails only reveals the following difference:

0.142108 ptp(2): PTP: Opening session
0.142143 gphoto2-port(2): Writing 16=0x10 byte(s) to port...
0.142169 gphoto2-port(3): Hexdump of 16 = 0x10 bytes follows:
0000 10 00 00 00 01 00 02 10-00 00 00 00 01 00 00 00 ................

0.142279 gphoto2-port(2): Reading 512=0x200 bytes from port...
0.142385 gphoto2-port(2): Could only read 12 out of 512 byte(s)
0.142434 gphoto2-port(3): Hexdump of 12 = 0xc bytes follows:
0000 0c 00 00 00 03 00 01 20-04 00 00 00 ....... .... 

0.142482 gphoto2-port(2): Writing 12=0xc byte(s) to port...
0.142525 gphoto2-port(3): Hexdump of 12 = 0xc bytes follows:
0000 0c 00 00 00 01 00 01 10-01 00 00 00 ............ 

0.142633 gphoto2-port(2): Reading 512=0x200 bytes from port...
0.144133 gphoto2-port(2): Could only read 12 out of 512 byte(s)
0.144156 gphoto2-port(3): Hexdump of 12 = 0xc bytes follows:
0000 0c 00 00 00 03 00 04 20-01 00 00 00 ....... .... 

0.144198 context(0): PTP Protocol error, data expected

From my limited knowledge of PTP, I think this might actually be a gphoto bug. The last read is a PTP_RC_InvalidTransa ctionID response, following a 'Get Device Info' request. Looks like the request needed a transaction id but didn't have one. (As a side note, the PTP error handling isn't the best at this point- it just tells you what it was expecting to get instead of the actual error). I'll look at this in more detail later.

[ckaga2000]

Originally Posted by SonuvBob

The same thing happened with the problem we ran into when the T10 had a certain numbers of files and folders on it. Couldn't use it again with gphoto2 until a file was deleted (or added). Are you sure it's an issue with the size?

No, thinking about it now that's probably "cum hoc ergo propter hoc" reasoning on my part. Given my song selection for the T10, all of them are very close to each-other in size. It could easily be the number of files is the limiting factor, with the size only being coincedental.

Originally Posted by SonuvBob

From my limited knowledge of PTP, I think this might actually be a gphoto bug. The last read is a PTP_RC_InvalidTransa ctionID response, following a 'Get Device Info' request. Looks like the request needed a transaction id but didn't have one. (As a side note, the PTP error handling isn't the best at this point- it just tells you what it was expecting to get instead of the actual error). I'll look at this in more detail later.

Ah. Well one thing I can tell you, after looking at the source code, is how little I really know about this stuff.

I guess there's nothing to it but to sit down and read up on anything I can, in what free time I've had for it of late. In addition to hoping someone else comes up with a patch or work-around. Until it can be resolved, live with only 10 CDs worth of music on my portable. Okay that's not so bad, but it's a matter of getting my money's worth.

[SonuvBob]

If you're looking for a quick workaround, edit camlibs/ptp2/ptp.h in the libgphoto2 source and change PTP_USB_BULK_HS_MAX_ PACKET_LEN from 512 to 4096 (or higher if you expect to have >1000 files). Big thanks to OrthoB for figuring that out.

I finally got around to doing that, and it works great. Oddly enough it still gets that extra byte when there's exactly 124 object handles (resulting in a 513 byte packet instead of 512), though it doesn't seem to cause problems. I wonder if this happens every time the object handle list packet size is a multiple of 256 bytes (it happened for OrthoB at 768 bytes).

[nibbler]

Originally Posted by SonuvBob

If you're looking for a quick workaround, edit camlibs/ptp2/ptp.h in the libgphoto2 source and change PTP_USB_BULK_HS_MAX_ PACKET_LEN from 512 to 4096 (or higher if you expect to have >1000 files). Big thanks to OrthoB for figuring that out.

It's worth noting that the 4096 setting has now been incorporated into the CVS code for libgphoto2 2.1.99 and apparently this doesn't break the spec for USB. Also, support has been added in the ptp2 driver for a properly functioning progress bar for uploads but I haven't tried this yet.

I still get PTP errors with files of certain length being transferred though. However, the file seems intact on the device and all plays well.