Hi,
First post, so bear with me.
This may not technically be a bug, but am unaware of a better place to post.
I am trying to get the file listing from my Sony Xperia Z3 Compact (it has a 64G SD card, full of music and photos) by calling LIBMTP_Get_Filelisting_With_Callback.
The function did not return for an hour.
The supplied progress function was not called either.
This gave the impression of libmtp (ver. 1.1.14) freezing.
To be fair libmtp does work correctly.
I did some debugging to find out that LIBMTPGetFilelistingWithCallback calls
flush_handles, which in turn either calls get_all_metadata_fast if supported by the device or uses the classic method by calling get_handles_recursively (which gets the data using ptp_getobjecthandles).
My Z3C does not support get_all_metadata_fast, so all the data was read via ptp_getobjecthandles. This took about an hour without any progress being indicated.
The problem is, that the end-user is unaware that the program is working normally. Neither is the developer, who provided the callback, which was never fired (well, it does get called after flush_handles returns, while processing the returned object list. One just has to be very patient).
Finally the questions/proposals - is it possible to hook the progress function also to the lower levels of libmtp - e.g. to get_handles_recursively or other appropriate function?
I am aware that the total number of objects may not be known at the time of calling but returning some magic number (e.g. MAXINT) may circumvent the problem.
Is there a better way to read the files either faster and/or indicating the progress of the caching?
It someone finds a working solution, probably it can be applied also to implement a function getting the folders with a callback (e.g. LIBMTP_IBMTP_Get_Folder_List_With_Callback)? It also takes ages on my Z3C.
Thanks for any tips/feedback.
Boyan.
Anonymous