GNOME Bugzilla – Bug 746983
MTP: problem with seek/stream API
Last modified: 2018-09-21 17:47:02 UTC
Hi, trying to investigate why my media player (parole) could play videos on a smb share and not on my android phone (MTP) share, I might have experienced a bug in the gvfs MTP backend. I've first tried to debug this with gstreamer people, since the media player uses gstreamer. Basically we noticed that: - parole doesn't play - gst-play-1.0 doesn't play - gst-launch-1.0 giosrc location=mtp://... ! filesink location=foo doesn't copy the file - gvfs-copy does copy the file - gvfs-cat doesn't output the file gvfs-copy apparently uses g_file_copy() while gvfs-cat (and the gst pipeline) use g_input_stream_read(). I know MTP is a bit special, but Android supports some extensions to make files seekable, and it seems that g_seekable_can_seek() returns TRUE.
Also, this is on Debian sid (with gvfs packages from both sid/1.22 and experimental/1.23.92). If you need any more information, please ask.
Two things we noticed: - g_input_stream_read() returns 0 immediately, which according to the docs must only happen on end-of-file. This is the main problem. - g_seekable_can_seek() returns TRUE, but I don't think libmtp supports seeking at all.
Unless the device supports the android seeking extensions, you will not have seek support. Unless the tool you use has explicit support for using g_file_copy() instead of seek/read, then it doesn't matter what gets declared as supported or unsupported, it's not going to work. And none of the tools you've listed except gvfs-copy support copying (unsurprisngly). mtp is not posix compliant without those extensions.
It should not provide the GInput/OutputStream API then, and also not report seekability via g_seekable_can_seek()... if it can't actually do all that. By claiming to support all this and then silently failing without a proper error, applications can't report the problem to the user in a meaningful way.
Also, the device is an Android device (Sony Xperia Z1 Compact, if that matters), running 4.4.4. I'm unsure how to check if the seeking extensions are really supported, any pointer welcome.
In that case I expect the device is claiming support for the direct I/O extensions, which is why you do not see the backend returning 'unsupported' when you try and open the file for seeking. I cannot comment on why the direct I/O calls appear to be failing for you, as I don't have the device to test on. Given that the backend works correctly on Nexus devices running stock Android, I suspect a device side problem - perhaps due to modifications Sony is making to the MTP stack, or device initialisation issues, or really anything. Can you grab an mtp-info dump from the libmtp tools?
I can try, but it seems I'm not able to find the mtp-info you're talking about. I cloned the repository at git://git.code.sf.net/p/libmtp/code and I can't find it there. Any url?
Created attachment 300550 [details] mtp-detect output Ok, here's the result with mtp-detect. not sure if it's relevant, but I also get a log: Mar 29 23:47:48 scapa kernel: [995388.681708] usb 1-1.1: usbfs: process 8858 (mtp-detect) did not claim interface 0 before use
The device claims to support the extensions, so that's why gvfs exposes seekable methods. What more can I say.
Well, if the device supports the extensions, I'd somehow assume it should work then, and it obviously doesn't. I already went from the application to gstreamer, then to gvfs-mtp, I can try to dig further (to libmtp or usb or whatever). Any pointer appreciated on how to debug those, though. I might also be able to try on a completely different stack (wether Mac OSX or some Windows) if it can help narrow down the problem.
If you're having fun ;-) I suggest sticking some debug printfs in libmtp. You can start in src/libmtp.c:LIBMTP_GetPartialObject and follow the logic from there... You probably also want to restart gvfs in debug mode so you can see the output from the printfs: pkill gvfs; GVFS_DEBUG=all `find /usr/lib* -name 'gvfsd'`
(In reply to Ross Lagerwall from comment #11) > If you're having fun ;-) It's not really for the fun, to be honest. I would just like to be able to play some files from the device directly, like it's supposed to work. > I suggest sticking some debug printfs in libmtp. > > You can start in src/libmtp.c:LIBMTP_GetPartialObject and follow the logic > from there... > > You probably also want to restart gvfs in debug mode so you can see the > output from the printfs: > pkill gvfs; GVFS_DEBUG=all `find /usr/lib* -name 'gvfsd'` Is there some kind of mtp-cat which would be an equivalent of gvfs-cat, using the LIBMTP_GetPartialObject(), so I could rule gvfs completely out of the equation?
(In reply to Yves-Alexis Perez from comment #12) > > You probably also want to restart gvfs in debug mode so you can see the > > output from the printfs: > > pkill gvfs; GVFS_DEBUG=all `find /usr/lib* -name 'gvfsd'` > > Is there some kind of mtp-cat which would be an equivalent of gvfs-cat, > using the LIBMTP_GetPartialObject(), so I could rule gvfs completely out of > the equation? Not that I know of.
There are no libmtp utilities that exercise any of the Direct I/O extensions.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/247.