GNOME Bugzilla – Bug 765843
Thumbnailing videos on an MTP camera (gvfs gphoto2) causes full video transfer
Last modified: 2018-09-21 17:58:54 UTC
Created attachment 327071 [details] [review] patch This is an alternative/complement to bug 738503. PTP/MTP is a file transfer protocol, not file access. Meaning that the entire file needs to be fetched just to read a single byte. This clashes badly with the automatic thumbnailing as the device can be locked up for multiple minutes just by opening it. In practice this makes the gphoto2 backend useless (at least for large files) unless you completely disable thumbnails. So since this backend is so inherently slow, I suggest switching from G_FILESYSTEM_PREVIEW_TYPE_IF_LOCAL to G_FILESYSTEM_PREVIEW_TYPE_NEVER. See attached patch.
Gphoto2 backend provides preview icons for pictures and also videos. The client applications should use this icon instead of generating new one, that's why _IF_LOCAL is used. I suppose that _NEVER causes that previews aren't used at all, which is wrong. Or are the preview icons used if _NEVER is used? The GIO documentation seems to be a bit vague in this case, or let's say that this case is not covered by the documentation... We can probably provide another enum which says something like "never generate thumbnails, use preview::icon if available", but it is probably redundant. We can use _NEVER as you proposed, however it needs to be documented well in GIO and also we have to be sure that "preview::icon" is used in such cases...
Yeah, I also noticed that ambiguity. And it would be nice to have it resolved. But until then I think you need to err on the side that makes the thing actually work in practice. Right now you have to disable previews globally to have a working MTP device, effectively changing every backend to _NEVER. I also assume that preview icons can be missing from the MTP device? And in such case it is probably still a bad idea to read in the file just to generate a thumbnail. And this needs to be communicated to the application. (I have not tested if applications will fall back to the preview property on _NEVER)
So I've tested it, Nautilus does not show thumbnails if _NEVER is set and preview icons are available...
(In reply to Pierre Ossman from comment #2) > Yeah, I also noticed that ambiguity. And it would be nice to have it > resolved. But until then I think you need to err on the side that makes the > thing actually work in practice. Right now you have to disable previews > globally to have a working MTP device, effectively changing every backend to > _NEVER. > > I also assume that preview icons can be missing from the MTP device? And in > such case it is probably still a bad idea to read in the file just to > generate a thumbnail. And this needs to be communicated to the application. You are right _IF_LOCAL doesn't make sense for such backend. _IF_LOCAL should be used only for backends based on the local files (i.e. recent, trash...). Let's push this and file bug report against Nautilus that it should show preview icons if available regardless of G_FILE_ATTRIBUTE_FILESYSTEM_USE_PREVIEW.
Comment on attachment 327071 [details] [review] patch commit 6defa47377bda3041c804483e172734d08ebddb6
I pushed the patch to master with slightly modified commit messages, however I afraid pushing this into stable branches... Gphoto2 backend is often used with images. I do not see any significant slowdown for images. You can disable thumbnailing in Nautilus if you have problems with videos, but you can't enable it if _NEVER is used. I afraid people would start complaining that they can't see thumbnails... I think we can push it to stable only if Nautilus change its behavioral...
So I filled Bug 765987 for Nautilus...
That's unfortunate, but I can understand your position. Hopefully there can be a change to nautilus in its stable branches, which could then allow this to move forward there as well.
-- 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/280.